The pub/sub model of MigratoryData functions as follows: When a new subscriber connects to a MigratoryData server within a cluster of one or more servers and subscribes to a subject, say X, the server first sends a snapshot message of subject X to the new subscriber (if one exists). Subsequently, as soon as the MigratoryData cluster receives any real-time messages from publishers for subject X, the MigratoryData server sends those messages immediately to the new subscriber.

Once a message is sent by a publisher to a server in a MigratoryData cluster, it is automatically propagated to every server in the cluster, ensuring that the message is accessible on all MigratoryData servers in the cluster.

When the client is no longer interested in receiving messages with subject X, it can unsubscribe from that subject.

Example

The following diagram shows an example of pub/sub interaction. Note that Subscriber 1 is only subscribed to subject A, and as a result, it exclusively receives messages related to subject A. It does not receive any messages related to subject B, as it has not subscribed to it.

Loose coupling

MigratoryData enables publishers and subscribers to be loosely coupled. All they share are subjects, which are abstract by nature. As a result, publishers and subscribers can operate independently without requiring knowledge of one another.

Tight coupling using an extension. The recommended approach is to use the default loosely coupled approach, but there may be situations where a publisher needs to publish messages on-demand for a specific subject, only when there is at least one subscriber for that subject. In such cases, this tightly coupled approach can be achieved using the Interactive Publishing extension.