Topic 11.7
Asynchronous Communication (Kafka/Queue)
In one line
Fire events and let each service react: the decoupling engine behind microservices.
Think of it like this
Dropping a note in someone's mailbox and continuing your day; they'll read and act on it whenever they get to it, and you don't have to stand there waiting.
Key ideas
- 01
Event-driven: service A publishes OrderPlaced; services B, C react independently — no A knows them.
- 02
Values: decoupling (add consumers freely), resilience (producer doesn't wait), buffering, replay (Kafka).
- 03
Costs: eventual consistency (B may lag), debugging across hops, no synchronous error surface for the caller.
- 04
Command vs event: commands tell (do X), events state (X happened) — events are the safer, replayable contract.
- 05
Sagas/outbox (11.13/11.14) are the standard companions — async isn't 'free', it's 'differently paid'.
- 06
Interview: 'order placement publishes OrderPlaced; inventory, billing, and notifications each subscribe — no fan-out code in the producer'.
Java / Spring map
- →
Spring Kafka producers/consumers; @TransactionalEventListener for outbox-safe publishing.
Explain without notes
The producer crashes after DB commit but before the event publish — which pattern makes this impossible (outbox)?
Practice
Model the order→{inventory, billing, events} fan-out with a Kafka topic and per-service consumer groups.
Trade-offs
- ↔
Great decoupling of scale, paid in consistency lag and a monitoring bill.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I can sketch an event fan-out and name the outbox/saga companions.