Delivery Assurance: Multiple Stores

A persistence store can serve as a redundant message path for exactly one combined message stream. When a suite of application programs communicate using two or more disjoint message streams, use a separate store to back each of the message streams.

Note: While persistence stores can potentially contain large quantities of message data, each store is itself a lightweight object. When the situation requires multiple stores, use as many as is appropriate.

Using one store inappropriately to back two or more direct message streams is a configuration error.

Two Stores

Two message streams are disjoint when they travel among disjoint networks of endpoints. For example, the first diagram (preceding) depicts a suite of three application programs: App1 sends a stream of messages from endpoint E1 to endpoint E2 in App2. App2 in turn sends a different stream of messages from endpoint E3 to endpoint E4 in App3. The two message streams are disjoint, even though E2 and E3 are both endpoints in App2. Because the message streams are disjoint, each requires its own store.

Larger Disjoint Networks of Endpoints

The preceding diagram depicted only one publisher feeding into each persistence store, and only one subscriber depending on each store. The following diagram depicts the same application suite in a more complex configuration, with two instances of each program.

Two Stores with Many Publishers and Subscribers

The second diagram shows that each of the two stores serves a separate network of endpoints. Store1 serves E1 and E2, while Store2 serves E3 and E4.

Notice that in the second diagram each E1 publisher has a direct path to every E2 subscriber. Similarly, every E3 publisher has a direct path to every E4 subscriber. The stores provide parallel indirect paths.

Store1 merges the message streams from all the E1 publishers, and guarantees that all the E2 subscribers receive all the messages in that combined message stream. Similarly, Store2 merges the message streams from all the E3 publishers, and guarantees that all the E4 subscribers receive all the messages in that combined message stream.

Violation of the Non-Merging Requirement

Violating the non-merging requirement is a configuration error, and causes incorrect results.

The third diagram (following) illustrates this error by modifying the example of the first diagram to erroneously use one persistence store instead of two.

Erroneously Using One Store Instead of Two

In this erroneous configuration Store1 collects messages from publishers at E1 in App1 and E3 in App2, and merges them into a combined message stream. Then Store1 ensures that all of its subscribers, at E2 in App2 and E4 in App3, receive every message of the combined message stream. That is, messages that App1 sends to App2 erroneously arrive at App3. Messages that App2 sends to App3 also erroneously arrive at App2.

These results are clearly incorrect. They do not match the intent. Compare this third diagram with the first diagram. Furthermore, this outcome results directly from violating the non-merging requirement:

  • Store1 connects E1 to E4, even though no direct path connects them.
  • Store1 connects E3 to E2, even though no direct path connects them.
Related concepts