Kafka & pub/sub.
A newspaper: published once, and any number of subscribers read it at their own pace.
Imagine breaking news. The reporter does not phone every reader one by one. The story is printed once, and whoever is interested picks up the paper — now, or later, at whatever pace they read.
Kafka works like that newspaper. Producers publish events to an ordered log; any number of consumers subscribe and read them independently. The publisher never has to know or wait for the readers, which lets parts of a system talk without being wired tightly together.
- Still calling everyone…1
The old way: phone every interested party, one by one. Slow and brittle.
- 2
Instead, publish once to an ordered log — like printing the paper.
- 3
Many subscribers read the same log, each tracking its own place.
- Catch up later? Fine.4
A slow reader doesn’t hold up the others — the paper just waits to be read.
- 5
The log is kept, so a reader can replay from the start when needed.
- 6
Producers and consumers never touch directly — add either side freely.
Decoupling is the real win
When services call each other directly, every new listener means changing the caller, and one slow listener can stall everything. Publishing to a shared log breaks that link: the producer just appends events and moves on; consumers come and go on their own. You can add a new consumer — say, an analytics job — without the producer ever knowing.
A log, not a queue
Unlike a simple queue where reading removes the message, Kafka keeps events on the log for a set time. Each consumer tracks its own position (its “offset”), so different consumers read at different speeds, and one can rewind to reprocess history. That retained, replayable log is what makes Kafka good for event streaming, not just one-off message passing.