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. Business processes that span multiple services and need all-or-nothing semantics without distributed transactions. When a single database transaction suffices. When the compensating actions are harder to implement correctly than the forward actions.