Pub/Sub (the baseline)
Who uses it: Developer building a first event-driven system
Producer publishes to a topic, broker fans out to subscribers
No event store — events are processed and forgotten
Each consumer maintains its own offset / position
At-least-once delivery; consumers handle duplicates
Examples: Kafka topics, RabbitMQ exchanges, AWS SNS
Why this works: Pub/sub is the cleanest starting pattern — events flow once from producer to subscribers and aren't kept. The diagram has no event store because reprocessing isn't a requirement at this stage.
Event sourcing
Who uses it: Team where the event log is the source of truth
Every state change is recorded as an immutable event
Current state is derived by replaying events
Event store is the system of record, not a side effect
New consumers can rebuild state by replaying from the start
Audit and time-travel queries become trivial
Why this works: Event sourcing makes the event log canonical — the diagram puts the event store in the center, because state is derived from it rather than stored in service databases. Adding a new view means writing a new consumer that replays history.
Service choreography
Who uses it: Team coordinating microservices without an orchestrator
No central coordinator — services react to each other's events
Order placed → inventory holds → payment authorizes → shipping books
Each step emits an event the next service subscribes to
Easier to scale, harder to trace end-to-end
Compensation events handle failures (saga pattern)
Why this works: Choreography lets services react to each other's events without a central orchestrator — the diagram shows a chain of producer-consumer relationships, with each service playing both roles, which scales well but makes tracing harder than orchestration.
CQRS with event projection
Who uses it: Team separating write and read models
Write side: commands produce events into the bus
Events project to one or more read models
Read models optimized per query (search, dashboard, API)
Eventual consistency between write and read
Read models rebuildable by replaying events
Why this works: CQRS with projections is event-driven by design — the diagram pairs a write-side event log with multiple read-side projections, so each query gets a denormalized view shaped to its access pattern.
