1 min lesson
At-least-once delivery plus idempotent consumers
Describe what "The answer that wins the room" changes in practice.
Step 1 of 3
The answer that wins the roomsay it in one breath
When an interviewer asks how you guarantee delivery, lead with the default and the consequence in the same sentence: at-least-once delivery plus idempotent consumers. That single clause tells them you know exactly-once is fiction and that you have already decided who owns dedup.
"I default to at-least-once delivery, then make every consumer idempotent so a duplicate is a no-op. That gives me exactly-once processing without pretending I have exactly-once delivery, which doesn't exist across a network."
Learn more
Full explanation
Ordering: expensive and usually not what you need
Ordering: expensive and usually not what you needglobal vs per-key vs none
Strict global ordering forces serialization, which kills throughput and creates a single point of contention. Most webhook problems only need ordering within a key, like a single repository or a single tenant. Be ready to size the requirement instead of granting it by reflex.
- No ordering
- Cheapest, fully parallel. Fine when each event is self-contained (e.g. "build finished").
- Per-key ordering
- Order within a partition key (repo, tenant, resource). Scales horizontally; the usual right answer.
- Global ordering
- One serialized stream. Reach for it only when a downstream genuinely needs total order and pay for it knowingly.
"created then deleted" arriving out of order matters; two unrelated push events do not. Order per resource, not globally.