Retries and slow responses

The network drops in the middle of an operation. Press the button twice and see what ends up in the database — with an idempotency key and without one.

Tap a part of the diagram to open that step.

The whole picture

A key per operation turns a retry from a second charge into a read of a stored result. An asynchronous contract turns waiting into a subscription. Both are about the same thing: the network is unreliable, and that is the normal case rather than the exception.

What's inside

  1. 1 The request and the dropped connection — Turn on "break the network after the charge" and press the button twice.
  2. 2 What the server does — The key is invented by the client, one per operation, and repeated on every retry.
  3. 3 Without a key — duplicates — Retries are not only made by people: browsers, proxies and job queues make them too.
  4. 4 With a key — one record — The row is created before the action itself, otherwise two simultaneous retries race straight past each other.
  5. 5 A slow answer: 504 or 202 — Streaming needs proxy buffering switched off, otherwise the whole answer arrives in one lump at the end.

Explorable Explanations

1 / 5