Premium

Publish-Subscribe

Basic System Design
≈ 2 min read

The Publisher Does Not Choose One Specific Receiver

With Publish-Subscribe, a publisher sends an event to a channel or topic, and every interested subscriber gets its own opportunity to process it. 

                 -> Analytics
OrderCreated ->  -> Email
                 -> Loyalty

The order service reports the OrderCreated fact, but it does not need to know how many consumers exist or what each of them will do with the event.

This Reduces Direct Coupling

A new subscriber can be added without changing the publisher: for example, audit or analytics can be connected to an existing event. The publisher depends on the event contract, but not on the API of every consumer.

At the same time, an event should describe a fact that has already happened and be understandable outside the producer's internal code. An overly technical event quickly turns one service's hidden implementation into a dependency for all the others.

Subscribers Work Independently

Failure of one consumer does not have to stop the others: analytics may temporarily lag while an email to the user has already been sent successfully. This is why pub/sub fits several independent reactions to one fact.

Publish-Subscribe is not a broadcast method call. The publisher reports an event, and each subscriber decides how to react to it and whether it needs that data stream at all.
Back Next