Architecture
Event-Driven Architecture: A Practical Guide
Commands, events, idempotency, projections, and the authority boundaries that keep event-driven systems understandable.
Define the authority boundary
Accept commands through a trusted service. Validate identity, permissions, and domain invariants before recording a business event. An event records an accepted fact; a command expresses an intention that can still be rejected.
Design for retries
Give each command a stable identifier and persist its accepted result. Consumers must handle duplicate delivery without repeating business effects. Store changes and an outbox entry together, then deliver asynchronously.
Make projections recoverable
Track which events each projection has processed. Rebuild read models from retained events and compare results before switching readers. Monitor queue age and failed deliveries so delayed processing stays visible.
These notes describe engineering patterns, not guarantees that a particular architecture or control is sufficient for every deployment.