The duality of request/reply vs. publish/subscribe #2

In my last post, I described how the mechanics of publish/subscribe actually mirror those of request/reply.

In this post, I’ll look at the two operation from another angle: What do they mean?

What does it mean when you bus.Send?

Sending means either that the sender wants to

  • Command that another service does something.
  • Request that another service does something, and yields one or more replies[1. Note that the request/reply pattern may impose unwanted temporal coupling in an architecture and should probably be used only in integration scenarios orchestrated by a saga.].

This means that the sender knows stuff about the other service, but that other service will most likely not know or care about who’s sending. In other words, the sender depends on that other service!

What does it mean when you bus.Publish?

Publishing means that the publisher wants to

  • Broadcast an event that contains information on something that has happened.

This means that the publisher most likely does stuff inside itself, maybe updates some internal state, and then goes on and publishes information on some aspect of what has happened. In doing this, the publisher will most likely not know or care about who’s receiving. In other words, the subscriber depends on the publisher!

Summing it up with a picture

Consider this illustration, where service dependencies are shown with arrows:

Again, see how comparing Send to Publish is actually like comparing two mirror images when the other mirror image is upside-down?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.