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