Forward deployed round
Webhook Idempotency & Ordering Coding Problem
Written and reviewed by Sahil Srivastav
What this interview round tests
Webhooks are how external systems tell you what happened, and they come with two guarantees you cannot change: the same event may be delivered more than once, and events may arrive out of order. A handler that assumes exactly-once, in-order delivery corrupts state the first time reality intervenes — which is always.
Interviewers use this because consuming events correctly is a defining forward deployed skill. A duplicate delivery double-applies unless you dedupe by event id. A reordered pair of updates leaves stale state unless you apply by version. Both are invisible in a happy-path test and inevitable in production.
The scenario
You are given a webhook handler that updates local state from a stream of events. The tests replay duplicate events and deliver updates out of order, and the handler mishandles both — applying duplicates twice and letting an older event overwrite a newer one.
Your job is to make the handler idempotent and order-correct: dedupe by event id so replays are harmless, and apply by version so a late, older event never clobbers newer state.
What you’ll practice
- Idempotent event handling: dedupe by event id
- Applying updates by version so ordering cannot corrupt state
- Distinguishing at-least-once delivery from exactly-once
- Making a handler safe under replay and reordering
- Testing against duplicated and shuffled event streams
How to approach it
Two guarantees you cannot change drive this: the same event can arrive more than once, and events can arrive out of order. Ask what would make a redelivered event harmless to process again, and what should decide whether an incoming event overwrites the state you already hold — arrival, or something intrinsic to the event.
The replayed and shuffled test streams define correctness — after processing them in any order, the final state must be the same as processing each event once, in order.
The starter repository ships with a failing test suite and a bundled verify.sh. Reviewed reference solutions are part of Gronex Pro — this page stays spoiler-free on purpose.
FAQ
Why can’t I rely on webhooks arriving once and in order?
Because providers guarantee at-least-once delivery, not exactly-once, and network paths reorder. Retries and redeliveries are normal. A correct consumer is idempotent and order-tolerant by design.
How is applying by version different from applying by arrival?
Arrival order is whatever the network produced; version is the true order of events. Applying by version means a newer state is never overwritten by a late older event, which arrival-order handling would allow.