SevyDevy

Module 6 · Doing Work Later, Safely · Lesson 24 of 35

What is pub sub? One event, many listeners

11 minFree System design course · Beginner to intermediateLesson 6.2By Saket Bhatnagar

Researched and drafted with AI, reviewed and edited by Saket Bhatnagar.

In short

  • What is pub sub? A publisher announces each event (a note that something happened) once, and every interested subscriber gets its own copy.
  • Think of radio cricket commentary: one voice, lakhs of listeners, each at their own pace.
  • A queue gives each message to one worker. In pub/sub every listener gets every event, but not always in the order they were sent.
Soon

Video lesson · coming soon

What is pub sub? One event, many listeners

Lala, your AI mentor, will walk you through this lesson in a short animated video. Until then, everything is here to read and try.

  1. 01 Two teams, half the bookings each
  2. 02 One commentator, lakhs of listeners
  3. 03 One topic, three listener groups
  4. 04 Queue or topic? Flip the cards
  5. 05 The booking id keeps order
  6. 06 Next: one event, read twice

That is lesson 23’s question: marketing, loyalty points and analytics all want to know about every booking. One queue, many listeners? Arjun Nair thinks so. He adds a booking queue with two new workers: one adds loyalty points, one counts bookings for Meera’s dashboard.

A week later, the loyalty team writes in: about half of all bookings never earned points. Meera Kulkarni’s dashboard shows half the bookings too. “Nothing crashed,” says Arjun. “So where did the other half go?”

Zoya Mirza draws lesson 23’s order rail of chits. “Each chit on that rail goes to one cook only. Loyalty and analytics are taking turns on the same chits.” What they need, she says, is radio commentary: one voice that every listener hears.

“And a busy station splits its commentary over several channels,” Zoya adds. Arjun frowns. “Then if a booking and its cancel go out on different channels, which one arrives first?”

What is pub sub?

In pub/sub, a publisher announces an event once and every interested subscriber gets its own copy. The name is short for publish and subscribe.

At SeatJaldi, the publisher is the booking service, the producer from the last lesson. Keep one line in your head: one announcement, many listeners, each at their own pace.

  • One announcement: the producer publishes each event once.
  • Many listeners: every group that cares gets its own copy.
  • Their own pace: a slow listener never holds up a fast one.
Try it yourselfShare the work, or tell everyone?For each SeatJaldi job, pick: one worker takes it, or every listener gets a copy.

You have seen this when one booking brings an SMS, an email and loyalty points. Behind the screen, one event was announced once, and several listeners acted on it.

You have seen it when a notification reaches your watch a few seconds after your phone. Each listener read the same news on its own schedule.

Queue vs pub sub: what is the difference?

A queue gives each message to one worker, and pub/sub gives each event to every listener. A kitchen chit goes to one cook; a radio voice reaches everyone.

Queue, pub/sub and a stored stream side by side
QuestionQueuePlain pub/subStored stream (next section)
Who gets a message?One workerEvery listenerEvery group gets all
After it is readRemovedThe publisher does not track itKept for a set time
OrderRoughly first in, first outNot promisedInside one channel
Best forSharing slow jobsTelling many parts one thingMany groups, reading again

What is a Kafka topic?

A topic is a named stream of events that groups of listeners read at their own pace. A stream means events written one after another and kept in a line, like a recording.

SeatJaldi’s topic, booking-events, lives in Kafka.

Like the station, Kafka keeps the recording: reading an event does not delete it.

Like a busy station, a topic splits its stream over several channels. Each channel is called a partition: a section of a topic, not the partitioning of lesson 16 or the network partition of lesson 22.

The answer to the pause: across partitions nothing is promised, so the cancel can arrive first. Each event can carry a key, a label such as its booking id. The producer picks the partition from that partition key. While the partition count stays the same, the same key always lands in the same one.

One topic, three listener groups

The booking service publishes one event per booking to a topic of several partitions. The SMS, loyalty and analytics groups each get every event and read at their own pace.

Diagram connections:

  • Booking service to booking-events topic (Publish event)
  • booking-events topic to SMS group (Reads own copy)
  • booking-events topic to Loyalty group (Reads own copy)
  • booking-events topic to Analytics group (Reads own copy)
  • Booking service: The producer: announces one event per booking.
  • booking-events topic: Several partitions; events with the same booking id stay in…
  • SMS group: Sends the Confirmed SMS; keeps its own bookmark.
  • Loyalty group: Adds points for the booking.
  • Analytics group: Counts bookings for the dashboard.

In Kafka, a subscriber is called a consumer.

Inside a group, members share the partitions like cooks share chits. Across groups, every group gets every event and keeps its own bookmark in the recording.

Try it yourselfQueue or topic? Flip and seeRead each front and guess what a topic does differently, then flip to check.

How do you choose partitions and keys?

Choose enough partitions for the most consumers you will need, and a key that keeps related events together. Within one group, each partition is read by only one consumer at a time.

Say 600 of lesson 10’s 800 booking requests a second end in a booking, and one SMS consumer handles 100 events a second (both assumptions). The group needs 600 / 100 = 6 consumers. Choose 12 partitions, twice that, so it can grow.

The producer uses hash mod N from lesson 18, with N the partition count. So adding partitions later can move a key to a new partition and break its order. Kafka does not move old events for you.

Kafka keeps events for seven days by default. Say 100 events a second at 500 bytes each (assumptions; a byte holds about one letter). That is 50,000 bytes a second.

A day has 86,400 seconds: 50,000 x 86,400 = 4.32 billion bytes, about 4.32 GB. Seven days is 4.32 x 7 = 30.24 GB. With 3 copies, 30.24 x 3 = 90.72 GB, about 91 GB.

Kafka’s tools show how far each group is behind the end of the topic. By default, Kafka may deliver the same event more than once, so a consumer can read it twice. The next lesson makes that safe.

One more surprise: a brand-new group starts at the newest event by default. To read the old ones, set it to start from the earliest.

bash
bin/kafka-topics.sh --bootstrap-server localhost:9092 \
  --create --topic booking-events \
  --partitions 12 \
  --replication-factor 3

What just happened? This makes booking-events with 12 partitions, each kept on 3 machines. It fails unless at least 3 Kafka servers are running.

json
{
  "type": "ticket.booked",
  "booking_id": "BK-10442",
  "match_id": 42,
  "seat_code": "A12"
}

What just happened? The producer sends the booking id as the key too, so BK-10442’s booking and cancel land on one partition, in order. To test it, publish 3 events each for two bookings; every group must see all 6, each booking’s in order.

Try it yourself

  1. Pick a key

    For booking events, choose booking id, match id or seat code. Does it spread load evenly and keep one booking’s events together?

  2. Say what breaks

    Write one line on what goes wrong with each of the other two keys.

  3. Check your answer

    Booking id keeps one booking together and spreads lakhs of bookings out. Match id overloads one consumer. Seat code splits a two-seat booking. You are right if every event of one booking shares your key and the key has many values.

Back to the missing half. Arjun swaps the booking queue for the booking-events topic. The SMS group takes SMS over from the ticket workers and now sends marketing’s “rate us” message too. The SMS, loyalty and analytics groups each get every booking.

Which piece arrives first? The booking id is the key, so a booking and its cancel share one channel and arrive in order. A fraud-check group added next week is set to start from the oldest kept event, so it plays the whole recording.

Meera has her line: “Every team hears every booking.” Then a complaint arrives. The SMS group got one event twice and sent two “Confirmed” messages. Worse: payment retries charged 214 users ₹299 twice.

Check yourself

Check yourself

Loyalty and analytics share one booking queue, and each sees half the bookings. Why?

Pick an answer to see why it is right or wrong.

Check yourself

Two events for one booking sit in different partitions. What can you rely on?

Pick an answer to see why it is right or wrong.

Check yourself

A new analytics group starts a week after launch. What can it read?

Pick an answer to see why it is right or wrong.

Remember these three

  1. One announcement, many listeners, each at their own pace: that is pub/sub.
  2. A queue shares work; a topic gives every consumer group every event.
  3. Order holds only inside a partition, so key by booking id and leave headroom in partitions.

Questions people ask

What is pub sub in simple words?
A publisher announces an event once, and every listener that cares gets its own copy. The publisher does not know who is listening, and each listener works at its own speed.
What is the difference between a queue and pub sub?
A queue gives each message to one worker, so workers share the work. Pub/sub gives each event to every listener, so each gets all of them.
What is a Kafka topic?
A Kafka topic is a named stream of events, split into partitions. Events are kept for a set time, each consumer group reads at its own pace, and order holds inside each partition.
Do events always arrive in order in pub sub?
No. In a Kafka topic, order is promised only within one partition. Give related events the same key, such as the booking id, so they share a partition and stay in order.