Ordering & Delivery Guarantees

The two questions that expose every event-driven architecture's real complexity: are events delivered in order, and are events delivered exactly once? The honest answers are "sometimes" and "no." Understanding why — and designing around that reality — is what separates production architectures from demos.

1. Ordering Guarantees Total ordering — every consumer sees every event in the same sequence — requires a single partition and a single consumer. This guarantees order but caps throughput. Partition ordering — events within a partition are ordered, events across partitions are not — allows parallel processing at the cost of global ordering. Choose the partition key carefully: order ID gives per-order ordering, customer ID gives per-customer ordering. The key determines what ordering guarantee the system provides.
2. At-Least-Once Delivery Most message brokers guarantee at-least-once delivery: every event will be delivered to at least one consumer at least one time. "At least" means duplicates happen — network retries, consumer crashes before acknowledgment, broker failovers. The architecture must handle duplicates gracefully. This is not an edge case. It is a steady-state reality.
3. Idempotency as Architecture If at-least-once delivery is the reality, idempotency is the requirement. Every event handler must produce the same result whether it processes an event once or five times. Track processed event IDs. Use conditional writes. Design state transitions that are naturally idempotent — setting a value is idempotent, incrementing a counter is not. Idempotency is not a feature. It is a survival requirement.