Command Palette

Search for a command to run...

Hectal
Phase 15Advanced16 of 18 in Apache Kafka

Event-Driven Architecture

Event-driven microservices with clear event ownership, sagas with compensation, event sourcing, CQRS read models, and replaying or backfilling history safely.

Kafka is most valuable as the backbone of an event-driven architecture: services publish facts about their own domain and react to others' facts, with no synchronous chains.

This phase covers the architectural patterns built on that idea, and the operational reality of each: compensation when steps fail, rebuilding read models, and reprocessing ten days of events without charging customers twice.

0/5 · 0%
5 topics ~39 min 7 code blocks & diagrams
Start with the first topic
1
15.1

Event-Driven Microservices: Ownership, Contracts, Evolution

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.

8 min 1 diagram practice

2
15.2

Sagas: Distributed Workflows with Compensation

A saga replaces a distributed transaction with a sequence of local transactions, each publishing an event; if a later step fails, compensating actions undo earlier ones (refund payment, cancel order). Implement with choreography or an orchestrator, and design for idempotency, timeouts and partial failures.

8 min 1 diagram 1 code practice

3
15.3

Event Sourcing

Event sourcing stores state as an append-only sequence of domain events; current state is the result of replaying them, often from a snapshot. Kafka can distribute and retain events, but an event-sourced system also needs per-aggregate reads, optimistic concurrency and snapshots, which a dedicated event store or database usually provides better.

7 min 1 code practice

4
15.4

CQRS and Read Models

CQRS separates the write model (validates commands, stores truth) from read models optimised for queries (search indexes, denormalised views, caches), kept up to date by consuming change events from Kafka. Read models are eventually consistent and can be rebuilt from events at any time.

8 min 1 diagram 1 code practice

5
15.5

Replay, Reprocessing, and Backfills

Replaying events fixes bugs and builds new views: reset a consumer group's offsets (or start a new group) to a time or offset and reprocess. The danger is side effects: replays must not resend emails, recharge cards or double-count, so separate pure projections from side-effecting consumers and rely on idempotency.

8 min 1 code practice