Topic 0.2
Why Kafka: From a REST Call Chain to Events
In one line
Synchronous REST chains couple services in time: one slow or failing service breaks the whole request. Publishing events to Kafka decouples producers from consumers, isolates failures, absorbs load spikes and allows replay, at the cost of eventual consistency and more moving parts.
Think of it like this
A relay race vs a noticeboard. In a relay, each runner must be ready to take the baton, and if one trips, the team stops. With a noticeboard, you pin a note ("order 9 placed") and walk away; whoever needs it reads it when ready, and a runner who is late just reads it later.
Key ideas
- 01
Temporal coupling: in
Order → Payment → Inventory → Notificationover REST, the order request waits for every downstream call. Latency adds up, and availability multiplies: four services at 99.9% each give roughly 99.6% for the chain. - 02
With events: the order service commits the order and publishes
OrderCreated; payment, inventory and notification consume it independently. The user gets a response after the order commit, not after the slowest downstream. - 03
Failure isolation: if notification is down for an hour, events wait in Kafka; when it recovers, it processes the backlog. No retries from the order service, no lost notifications.
- 04
Backpressure: a traffic spike becomes consumer lag instead of cascading timeouts. Consumers process at their own safe rate.
- 05
Costs: eventual consistency (the user sees "order placed" before payment completes), harder debugging (distributed tracing across async hops), schema contracts between teams, idempotent consumers, and a Kafka cluster to operate. Use REST when the caller genuinely needs the answer now ("is this card valid?").
Code & diagrams
Interview problem
The problem
Why Kafka instead of REST?
Order Service calls Payment, then Inventory, then Notification with synchronous REST. Redesign it around Kafka and discuss coupling, latency, failure isolation, retry, replay, ordering, durability, backpressure and operational complexity.
You're given
- 2K orders/sec peak
- Notification service is flaky
- Analytics wants every order event
The interviewer follows up
The UI must show payment success immediately. Does that break the event design?
Explain it without notes
How does an event-driven design change failure behaviour compared with a REST chain?
Practice
Take one synchronous call chain from a system you know and mark which calls could become events.
Trade-offs
- ↔
Decoupling and resilience vs eventual consistency, harder debugging and more infrastructure.
Done when you can
I can redesign a REST chain as event-driven and explain each benefit and cost.