Events and pub/sub

A queue hands each job to one worker. Sometimes many services need to know that something happened.

Publish and subscribe

A service publishes an event, a short note about something that happened, like "order 42 was placed". Every subscriber gets its own copy. The publisher sends it once and does not know who is listening.

Topics

Events go to a topic, a named channel for one kind of event, like "order-placed" or "user-signed-up". A service subscribes only to the topics it cares about. Events are named in the past tense, because they report facts, not orders to do something.

Decoupling

Without events, the order service calls email, shipping, and analytics one by one. If email is down, the order fails, and each new service means changing the order code.

With events, the order service just publishes "order placed". Email, shipping, and analytics each subscribe. If email is down, orders still go through, and email catches up later. Adding a new service needs no change to the order service. The cost: the full flow is harder to follow, since no single place shows every step.

Queue or pub/sub

• Queue: each job goes to one worker. Use it to share work.
• Pub/sub: each subscriber gets a copy. Use it to tell many services.

Ordering

A busy topic is split into partitions, handled in parallel. Order is only kept inside one partition. Each event has a key, like the order id, and events with the same key go to the same partition. So "order 42 placed" always comes before "order 42 cancelled", but events for different orders may be handled in any order.

Remember

• One event, many subscribers, each with its own copy.
• The publisher does not know or wait for subscribers.
• Queue: one worker per job. Pub/sub: a copy for each subscriber.
• Order is kept only for events with the same key.