Topic 15.1
Event-Driven Microservices: Ownership, Contracts, Evolution
In one line
In an event-driven architecture, each service owns its data and publishes events about it; other services subscribe instead of calling. It works when event ownership is clear, schemas are contracts, consumers are idempotent, retries and DLTs are standard, and events are versioned deliberately.
Think of it like this
Departments in a company using an internal newsletter. Sales announces "new contract signed"; finance, legal and delivery each act on it without Sales calling each of them. Each department owns its own announcements and never edits another's.
Key ideas
- 01
Ownership: one service (and team) owns each topic and its schema; others only consume. Avoid shared "integration" topics that several services write the same event type to.
- 02
Choreography: services react to each other's events (
OrderCreated→ payment →PaymentAuthorized→ inventory ...). Simple and decoupled, but the overall flow is implicit and harder to see. - 03
Orchestration: a coordinator (a saga orchestrator or workflow engine like Temporal) sends commands and tracks state. The flow is explicit and easier to monitor, at the cost of a central component.
- 04
Contracts: schemas in a registry with compatibility checks, events documented in a catalogue (AsyncAPI, Backstage), and clear semantics (units, IDs, what triggers the event).
- 05
Standard consumer kit per team: idempotency (inbox), retries with backoff, retry topics and DLT, tracing, lag and error metrics. Platform teams often provide this as a library or template.
- 06
Pitfalls: "every service consumes every event" (tight coupling in disguise), events that are really RPC (waiting for a reply event synchronously), and leaking internal table structure as events.
Code & diagrams
Interview problem
The problem
Order → Payment, Inventory, Notification via Kafka
Design the Kafka-based microservices architecture for an order flow with payment, inventory and notification services. Discuss loose coupling, event ownership, schemas, retries, DLTs, idempotency, ordering and event versioning.
Explain it without notes
Compare choreography and orchestration.
Practice
Draw the event flow for a hotel booking (booking, payment, room allocation, confirmation email) and assign topic ownership.
Trade-offs
- ↔
Event-driven designs decouple teams and absorb failures, but make end-to-end flows harder to trace and reason about.
Done when you can
I can design event-driven services with clear ownership, contracts and a standard reliability kit.