Story
Segment: delivering billions of messages exactly once
How Segment found some of its events arriving twice — and the dedupe pipeline it built to skip them.
12 minMediumMembers lesson
Membership isn’t open yet. The free lessons are open — 17 of them.
What you'll be able to do
- 1Predict where duplicate deliveries come from and how many reach downstream — a lost confirm, a worker crash after the work, a hiding timeout shorter than the work, a producer resending after an unclear answer.
- 2Choose a guarantee for a job from what losing it or doing it twice would cost, and read a broker's "exactly-once" feature for what it covers — the queue, not the consumer's side effects.
- 3Explain how a stable idempotency key and a record of handled keys, written together with the work in one transaction, turn at-least-once delivery into effectively-once processing — and why checking first and recording afterwards leaves a gap.
- 4Predict which repeats a deduplication window misses — a late redelivery, a dead-letter replay, a producer resend after the keys expired — and size the window from how long the broker can redeliver.
Inside the lesson
- steps
- 5
- questions
- 6
- simulations
- 2
You guess first, then run the system and see if you were right.
Step 1 · The setup
Segment's API takes in events from its customers' apps — a page viewed, a room booked — and passes them on. Customers count on those events: some add up their revenue from them.
In a 2017 post, Segment described how a small share of events arrived twice. Walk through where the repeats came from and how Segment removed them. Decide what you would do, then see what Segment did.
Steps 2–5 are for members