Part 4 · 1 chapters · ~8 min
Event-Driven Architecture: Choreography and Orchestration
Events versus commands, event notification versus event-carried state transfer, event sourcing and when it fits, choreography and orchestration compared, sagas and compensation, event schemas and versioning, and observability across asynchronous flows.
7
Events, commands and state
| style | message | trade-off |
|---|---|---|
| event notification | { type: 'payout.completed', id } | small; consumers call back for details (load and coupling) |
| event-carried state transfer | { type: 'payout.completed', id, amount, account, at } | consumers need no callback; larger events, schema discipline |
| event sourcing | the log of events is the source of truth | full history and replay; harder queries, migrations and GDPR deletion |
| command | { type: 'SendTransfer', payoutId } | asks one owner to act; can be rejected |
Name events in the past tense (they are facts) and commands in the imperative. Version event schemas (APIs course P5, Kafka course P6 on schema registries) and make every consumer idempotent.
CHOREOGRAPHY VERSUS ORCHESTRATION
the same payout flow, two ways
swipe the figure sideways, or tap expand for full screen
1/4
choreography
Each service reacts to events and emits its own. No central coordinator; services stay loosely coupled.
services react to eventsno single coordinator