Module 15 7 lessons 97 min

Messaging: Kafka and pub/sub

Placing an order calls payment, restaurant, rider, SMS and analytics one after another. If any of them is down, the order fails, even though most of them only need to know the order happened.

In this module

6 Read · 1 Lab

  1. 15.1Pub/subThe order service publishes “order placed” without knowing which services consume it.Read10 min
  2. 15.2How Kafka worksTopics, partitions and offsets, and why reading a message doesn't delete it.Read15 min
  3. 15.3Kafka as a queueConsumer groups split the work, the partition count limits how many consumers you can run, and slow consumers build up lag.Read12 min
  4. 15.4Fan-out and fan-inSending one event to many services, and combining several events into one result, such as waiting for payment and restaurant confirmation before assigning a rider.Read10 min
  5. 15.5Message orderingKafka keeps order only within a partition. Choose the key so all events for one order go to the same partition.Read10 min
  6. 15.6At most, at least, exactly onceWhat a message system can guarantee, and why exactly-once in practice means idempotent consumers.Read10 min
  7. 15.7Lab: Event-driven order flowConnect order, payment and rider services with events, then take one down.Lab30 min
Start with 15.1 · Pub/sub
Then · Module 16Transactions across services