Name of "notification-and-check" pubsub architecture?

Question

Basic pubsub architecture question. At a high level, when designing pubsub, I sometimes face a choice between two architectures:

1. Publish mutations or "new-state".

Some DB state is mutated, and publishers notify of that change via pubsub. But they include enough information in the message so that the subscriber doesn't need to do a look-up on the DB. Imagine the subscriber has a cache of the DB. It could receive the mutations or new-state, and update its cache without doing a look-up.

2. Notification-and-check The publishers only notify that "there is a new change", which prompts the subscriber to pull the latest from the DB. This is more robust IMO. The pubsub may not guarantee order of delivery, and this architecture is robust to that, while #1 is not, if the mutations are order-sensitive.

My question is, is there a common name for these 2-types of architectures? Thanks!

Tiresome

I don't agree that #2 is more robust: you need to replay all prior events to get to the final state, instead of just the latest event ; by the time the recipient polls to get data about the event, the data may be obsolete. Not saying #1 better, just saying there are pros and cons to each and usually one if the two will be better in your current situation, but not necessarily all your situations. – Doubletongue

Answer 1

Publish/Subscribe is known as the Observer Pattern in the Gang of Four Design Patterns book. On page 298 they describe these two variations as push and pull models.

Implementations of the Observer pattern often have the subject broadcast additional information about the change. The subject passes this information as an argument to Update. The amount of information may vary widely.

At one extreme, which we call the push model, the subject sends observers detailed information about the change , whether they want it or not. At the other extreme is the pull model; the subject sends nothing but the most minimal notification, and observers ask for details explicitly thereafter.

The pull model emphasizes the subject's ignorance of its observers, whereas the push model assumes subjects know something about their observers' needs. The push model might make observers less reusable, because Subject classes make assumptions about Observer classes that might not always be true. On the other hand, the pull model may be inefficient, because Observer classes must ascertain what changed without help from the Subject.

Aguie