Event-Driven Architecture
Publishing facts, and trading comprehensibility for decoupling.
4 to work through
-
intermediate
Before 2017 every consumer of published content at The New York Times integrated with each producing system's own API and bootstrapped its history by calling those APIs. The 2017 publishing pipeline replaced that with one Kafka log. What changed about the cost of adding the eleventh consumer, and about who pays for a backfill?
3 min answer -
advanced
A platform adopts event-driven architecture broadly and finds debugging and reasoning much harder. When is event-driven the wrong choice?
2 min answer -
advanced
A team proposes routing every internal workflow through an event-streaming platform because it is scalable and decoupled. What questions do you ask and when is a simpler mechanism correct?
3 min answer -
advanced
Review this design. Every service publishes one event type per aggregate - OrderChanged carries the whole order document plus a changeType string. Eleven consumers subscribe and each begins with a switch on changeType, ignoring types it does not care about. What would you remove, what would you change, and what would you leave alone?
3 min answer
2 terms in this topic
Broker and Mediator Topology
Two ways of organising an event-driven system — components reacting independently to a shared channel, or a central component coordinating a defined …
patternEvent-Driven Architecture
A style in which components communicate by publishing and reacting to facts, rather than by calling each other and waiting.
1 artifact you would hand over
Neighbouring topics
Architecture Patterns
General material on architectural patterns and their trade-offs.
Layered Architecture
The default shape, its clarity, and where a technical partition fails.
Pipes and Filters
Independent transformation steps composed into a pipeline.
Publish/Subscribe
Broadcast to every subscriber, as distinct from work distribution.
Competing Consumers
Scaling throughput with instances, at the cost of ordering.
Saga
Local transactions with compensating actions across services.
CQRS
Separate models for writing and reading, each optimised for its job.
Event Sourcing
The event log as the system of record, with state as a projection.
Outbox
Making the event atomic with the business write it describes.
Strangler Fig
Incremental replacement behind a routing facade.
Anti-Corruption Layer
Translating a foreign model at the boundary so it does not leak in.
Sidecar & Ambassador
Cross-cutting behaviour in a co-deployed process.
Service Mesh
Sidecars applied estate-wide, and the scale at which that pays.
API Gateway
A single entry point for policy, routing and protocol translation.
Backend for Frontend
A narrow backend per client experience, owned by that client's team.
Cell-Based Architecture
Complete isolated copies each serving a subset of customers.
Sharding Patterns
Directory versus embedded keys, logical shards and rebalancing.
Materialized Views
Precomputed query results, refreshed incrementally or in full.
Orchestration vs Choreography
A coordinator that knows the flow, or services that react to events.