System Type: Event-Driven

Patterns, guarantees, and failure modes for event-driven and message-based architectures.

Core Patterns

Publish/Subscribe

What it is. Producers publish events to a topic; consumers subscribe and receive independently. Decouples producers from consumers. When to use. Fan-out notifications, audit logging, updating multiple read models, cross-domain integration where the producer shouldn't know about consumers. When to avoid. When you need a synchronous response. When ordering across topics matters. When the number of consumers is always exactly one (point-to-point is simpler).

Event Sourcing

What it is. Store state as a sequence of immutable events rather than current-state snapshots. Current state is derived by replaying events. When to use. Audit requirements (financial, regulatory). When you need to reconstruct historical state. When different consumers need different projections of the same data. When to avoid. CRUD-heavy domains with simple state. When event schema evolution is harder than the audit benefit. When the team has no experience with eventual consistency patterns. When query patterns require complex joins across aggregates.

CQRS (Command Query Responsibility Segregation)

What it is. Separate the write model (commands) from the read model (queries). Each is optimized for its access pattern. When to use. When read and write patterns are drastically different (many reads, few writes, or vice versa). When you need different data shapes for different consumers. Pairs naturally with event sourcing. When to avoid. Simple domains where read and write models are essentially the same. When the consistency lag between write and read models is unacceptable. When the operational complexity of maintaining two models exceeds the benefit.

Saga Pattern

What it is. Coordinate a multi-step business process across services using a sequence of local transactions with compensating actions for rollback. When to use. Business processes that span multiple services and need all-or-nothing semantics without distributed transactions. When to avoid. When a single database transaction suffices. When the compensating actions are harder to implement correctly than the forward actions.

Choreography vs. Orchestration

Choreography: Each service listens for events and decides independently what to do next. No central coordinator. Good for simple flows with few steps. Becomes opaque when flows are complex — the process is implicit in the event chain. Orchestration: A central coordinator explicitly directs each step. Easier to understand, monitor, and modify complex flows. The orchestrator is a single point of failure and a coupling point. The real question: How many steps? Fewer than 4: choreography is simpler. More than 4: orchestration is easier to reason about and debug.

Delivery Guarantees

At-most-once. Fire and forget. Message may be lost. Use for: metrics, non-critical notifications, telemetry where gaps are acceptable.

At-least-once. Messages are retried until acknowledged. Messages may be delivered more than once. Use for: anything where losing a message is worse than processing it twice. Requires idempotent consumers.

Exactly-once. Each message processed exactly once. In distributed systems, this is achieved through at-least-once delivery + idempotent processing (not through the broker alone). Use for: financial transactions, inventory updates, anything where duplicates cause real harm.

The practical reality: Most systems use at-least-once delivery with idempotent consumers. Exactly-once semantics from the broker (e.g., Kafka transactions) have significant performance and complexity costs.

Idempotency in Consumers

Every consumer in an at-least-once system must handle duplicate messages safely.

Strategies:

…