software-engineer-blog logoSoftware Engineer Blog

Module 7 · Concurrency

Unit 27 of 49

Unit 27 · Module 7 · Concurrency

Idempotency

The property that makes retries safe — and without it, retries are a bug.

Unit 27 of the free 49-unit computer-science course, in concurrency. 2 topics to watch or read, 3 interview questions answered in full and a short self-check.

Watch or read

2 topics make up this unit. Take each one whichever way suits you, then answer the questions below.

At-least-once vs exactly-once

A customer taps Pay once and gets charged twice — with no bug in your code. Delivery semantics from first principles: why a lost acknowledgement makes at-most-once, at-least-once and 'exactly-once' inevitable, and why exactly-once is a property of your consumer, not a setting on your broker.

ReelRead

Interview questions this unit unlocks

Asked out loud, answered out loud. Read the answer, then say it in your own words.

What does idempotent mean, and which HTTP methods are?

Doing it twice has the same effect as doing it once. GET, PUT and DELETE are idempotent by definition — setting a resource to a value, or deleting it, lands in the same state however many times you repeat it. POST is not, which is why a double-submitted form charges the card twice. Note that idempotent is not the same as safe: DELETE changes state, it just does not change it further on a repeat.

How do you make a payment endpoint idempotent?

The client generates an idempotency key — a UUID, one per logical attempt, not per retry — and sends it with the request. The server stores it with the result in the same transaction as the charge. On a repeat, the key is already there, and it returns the original response instead of charging again. The key has to be written atomically with the effect, or a crash between the two reopens the exact hole you were closing.

The distinction interviewers dig at: the key must survive retries by the same client AND be scoped so two genuine purchases are never collapsed into one.

Why is exactly-once delivery usually a lie?

Because the network can lose the acknowledgement, not just the message — so the sender cannot distinguish "it never arrived" from "it arrived and the ack was lost", and it has to choose between resending (at-least-once) and not (at-most-once). What systems actually offer is at-least-once delivery plus idempotent processing, which produces exactly-once *effects*. That is a real guarantee, and it is the one you build.

Self-check — 3 questions

Answer alone, at 2am, with no interviewer in the room.

Part of Everything You Need to Know About Computer Science.