Module 94: Distributed Systems
Events
🏠The everyday picture
A newspaper is printed once and read by anyone who subscribes. The newspaper doesn't need to know its readers; new readers can subscribe at any time without changing how it's printed.
📘What it really is
-
A queue usually has one kind of consumer per job. Event-driven systems publish events that any number of subscribers can react to (publish/subscribe, or pub/sub).
-
In the booking platform,
SessionBooked(Module 93) might be consumed by: notifications (send emails), billing (start payment timeout), analytics (count bookings), tutor dashboard (update in real time). Adding a new consumer doesn't change the publisher. -
Two styles of event:
- notification events: small ("booking 812 was booked"), consumers fetch details if needed;
-
event-carried state: include the details consumers need (tutor, time, amount), so they don't call back.
-
Event design:
- a schema with a name, version, ID, time and payload; change it carefully (add fields, don't remove or rename them; version when you must);
- an event ID so consumers can ignore duplicates;
-
events state facts ("payment received"), not commands ("send email").
-
Ordering: events may arrive out of order; design consumers to cope (check versions or timestamps; ignore stale updates).
-
Event sourcing (an advanced pattern) stores the events themselves as the source of truth and rebuilds state from them; powerful for audit-heavy domains, but complex. Most systems store current state plus an outbox (Module 93).
-
Trade-off: events decouple parts, but the flow becomes harder to see; document who publishes and who consumes each event (an event catalogue), and trace them (Module 72).
🖱️Try it
Write an event catalogue for the booking platform: each event's name, version, fields, publisher and consumers. Change your Module 93 outbox worker to publish events to a pub/sub channel (Redis streams, or a simple table that several consumers read with their own "last seen" position). Add a new analytics consumer without touching the publisher, and test duplicate and out-of-order delivery.
✅Quick check
What's the main benefit of publish/subscribe?
Show the answer
New consumers can react to events without the publisher changing or even knowing about them.
Why shouldn't you rename fields in an existing event?
Show the answer
Existing consumers depend on them and would break; add new fields or version the event instead.