Billing Webhook Idempotency
The brief
You've been dropped into the billing service of a subscription business. A worker consumes subscription lifecycle webhooks (upgrade, downgrade, cancel, credit grants) from the payment provider and applies them to each account. The provider guarantees at-least-once delivery, not order. After a provider replay last Tuesday, paid accounts were double-granted their monthly credits, and a separate cohort got silently downgraded when a delayed "cancel" landed after a newer "upgrade" had already been applied. The worker trusts every event it sees.
Across five milestones you'll scope what "applied exactly once" actually means for money-moving events, decompose the webhook-to-entitlement pipeline to find exactly where duplicates and reordering slip through, commit to an idempotency and ordering contract that holds under replays and races, then fix the entitlement update path inside the real billing codebase until the duplicate-credit and stale-downgrade tests pass. Finally you'll defend your choices and grade yourself.
Why this company
Stripe interviews drop you into payments-grade correctness problems where the hard part is never the algorithm. It's reasoning about at-least-once delivery, idempotency, and ordering when the network and the provider are both allowed to lie to you. This lab mirrors that: the actual fix is a couple of guards, but the signal is whether you can scope "exactly once" precisely and defend it when a replay or a concurrent worker shows up.
What you'll do
- 1ClarifyPin down what “applied exactly once” means before you touch money.
- 2DecomposeMap the webhook-to-entitlement pipeline and name where duplicates and reordering slip in.
- 3DesignCommit to an idempotency + ordering contract and defend it under replays and races.
- 4BuildFix the entitlement update path in the real codebase until the duplicate and stale-event tests pass.
- 5ReviewDefend your contract against the concurrency curveball, then grade yourself.