Events, producers, consumers, and publish/subscribe

In the previous lesson, the backend gave the queue instructions: “send this receipt.” “Text the café.” “Add these loyalty points.”

Look closely at who had to know what.

The checkout code had to remember everything that should happen after an order: the email, the text, the loyalty update, the analytics record.

When the company adds a fifth follow-up next quarter, someone edits checkout again, and again for a sixth, and again for a seventh, and the busiest, most important code in the company slowly becomes a list of everyone else’s errands.

This lesson introduces the elegant escape: stop giving orders, and start making announcements.

What is an event?

An eventConcept · lights on your mapeventA statement that something happened, published as data for whoever cares: “order_placed, #1042, $14.50.” Not an instruction, a fact. The publisher does not know or care who is listening, which is exactly what makes events architectural glue. is a statement that something happened, recorded as data.

An event describing Erik’s order might look like:

Compare the two ways checkout can communicate:

• An instruction: “Send a receipt for order 1042.” It names a task and implies a doer.
• An event: “Order 1042 was placed.” It states a fact and implies nothing about what should happen next.

The difference sounds small, but architecturally it is enormous.

Checkout publishes the fact, its job is done, and it neither knows nor cares what happens next.

What are producers and consumers?

Event systems have two roles, a producer and consumer pair.

A producerConcept · lights on your mapproducerThe side that publishes an event: checkout announcing order_placed. It does not know which consumers exist, or whether any do. publishes events, and checkout produces order_placed.

A consumerConcept · lights on your mapconsumerThe side that subscribes to events and reacts: the email service hearing order_placed and sending the receipt. Many consumers can react to one event, and none of them knows the producer. receives events and reacts to them:

• The email service consumes the event and sends the receipt
• The notification service consumes it and texts the café
• The loyalty service consumes it and adds points
• The analytics pipeline consumes it and records the order

Two properties make this arrangement special.

First, one event can have many consumers. The same fact fans out to four reactions, or forty.

Second, neither side knows the other exists. Checkout does not know who is listening, and the loyalty service does not know who announced. They share only the event’s shape.

What is publish/subscribe?

This pattern has a name you will hear constantly: publish/subscribeConcept · lights on your mappublish/subscribeThe pattern where producers publish events to a named channel and any number of subscribers receive them, decoupling who-says from who-hears. Adding a new reaction means adding a subscriber; the publisher never changes. “Pub/sub” in conversation., shortened in conversation to pub/sub.

Producers publish events to a channel, consumers subscribe to it, and the messaging system delivers each event to every current subscriber.

You have met this idea twice before, in smaller forms.

Module 6’s webhooks were one system saying “we’ll call you when it happens”, a subscription with exactly one listener.

Module 8’s shelf included Amazon SNS, the Simple Notification Service, a managed pub/sub system. This lesson is what that service is for.

What is a topic?

The named channels that events are published to are called topicConcept · lights on your maptopicA named channel of events: “orders,” “payments,” “account-signups.” Producers publish to a topic; consumers subscribe to the topics they care about. Kafka is the heavyweight industrial machinery for exactly this.s.

The coffee company might operate:

• An orders topic, carrying order events
• A payments topic, carrying payment events
• An account-signups topic, carrying new-customer events

Consumers subscribe only to the topics they care about, so the fraud service might subscribe to orders and payments but ignore signups entirely.

In Module 7, you encountered the name Kafka among the data world’s tools, and Kafka is an industrial-strength platform for exactly this: streams of events, organized into topics, produced and consumed at enormous scale. The name should feel warmer now.

The diagram transformation

Here is why architects adore this pattern. Watch what happens to the arrows.

In the instruction-style design, checkout depends on five services. Five arrows leave the busiest box in the system, and, as this module keeps repeating, failures travel along dependency arrows.

In the event-style design, checkout depends on one thing, the topic, and the five consumers point at the topic, not at checkout.

Two payoffs follow.

Adding behavior stops requiring surgery. When the fraud team wants to react to orders, they subscribe to the topic. Checkout is never edited, never re-tested, never even told.

Consumer failures stop reaching the producer. If the email service goes down, checkout does not stumble. The service’s events wait for it to recover, the shock-absorber behavior from last lesson, applied to announcements.

How events relate to queues

Last lesson’s queue and this lesson’s topic can sound like the same thing. The distinction is worth making precise.

A queue message is typically a task intended for one doer. One worker takes it, performs it, and the message is gone.

An event on a topic is a fact intended for every subscriber, and each consumer receives its own copy.

In practice, real systems combine the two.

A classic arrangement gives each consumer its own queue, fed by the topic:

The topic handles the fan-out. Each queue then gives its consumer the previous lesson’s full toolkit: a private backlog, workers that drain it at their own pace, retries, and a shock absorber for busy days.

On AWS, this exact shape, SNS fanning out into SQS queues, is one of the most common patterns in production systems.

This is also why everyday engineering vocabulary blurs the words. The target sentence says the backend “publishes an event to a queue”, and now you can see why that phrasing works. The event is announced, and each interested consumer’s copy lands in a queue where a worker will process it.

The price of announcements

There is always a price, and for event-driven design it is legibility.

In the instruction-style world, one file of checkout code listed everything an order triggers. Anyone could read it.

In the event-style world, that behavior is spread across subscribers. “What all happens when an order is placed?” becomes a hard question, answered by tracing topic subscriptions instead of reading one file.

The fine print continues:

• Events are contracts. Consumers depend on the event’s fields and types. Renaming order_id breaks every subscriber. Module 6’s API-contract discipline applies to event payloads too.
• Duplicates still happen. Delivery is commonly at-least-once, so consumers must be idempotent, exactly like last lesson’s workers.
• Reactions complete at different times. The receipt may be sent before the loyalty points appear. For a while, different parts of the system reflect different amounts of the same fact.
• Silent failure needs watching. A subscriber that stops consuming hurts no one visibly, while its queue just grows. Monitoring, not user complaints, has to notice.

Architects accept these trades knowingly, and now you know them too.

The mental model to remember

An event is a fact that something happened, published as data, an announcement, not an instruction.

A producer publishes events. Consumers subscribe and react. One event can have many consumers, and neither side knows the other exists.

Publish/subscribe is the pattern that connects them through named channels called topics.

Adding a new reaction means adding a subscriber. The producer never changes, and consumer failures no longer reach it.

Topics commonly fan out into per-consumer queues, combining this lesson’s announcements with last lesson’s workers.

The price is legibility and coordination. Behavior spreads across subscribers, event payloads become contracts, and consumers must handle duplicates and watch their own health.

You should now hold every word of the target sentence’s final clause: the event, the queue, the asynchronous worker, and the notification it sends.