Video lesson: Retries Need an Operation Contract

Lesson promise

By the end, the learner should be able to explain the core model for retries need an operation contract, apply it to a concrete input, and identify when its usual shortcut or guarantee stops applying. This is a recording brief; publish it as a playable lesson after the narration and visual sequence have been produced and reviewed.

Narration draft

A retry repeats work after the caller cannot determine whether an earlier attempt completed. Timeouts create this ambiguity: the server may have committed the operation while the response was lost. Safe retry design begins by defining idempotency, deadlines, and which errors may be transient.

An idempotency key lets the service associate repeated attempts with one logical operation and return the recorded result. Exponential backoff with jitter spreads retries over time, while a retry budget limits amplification. Backpressure slows or rejects new work when queues or downstream services approach capacity.

Retrying every failure can turn a brief outage into a traffic surge. A timeout is not proof of failure, and retries at multiple layers multiply attempts. Queue length without a bound merely converts overload into rising latency and memory use.

Visual sequence

1. Put the input and assumptions on screen. Ask the learner to predict the next state before revealing it.
2. Animate the representation and show the operation one transition at a time.
3. Pause at the boundary case in the companion article and compare the result with the invariant.
4. End with the exercise prompt: A client retries three times, an API gateway retries twice, and a worker retries four times. Calculate the maximum downstream attempts for one request and propose where to enforce a shared retry budget.

Companion material

Use the article, trace, and interactive concept flow as the learner’s written and visual references. The video remains planned until an actual playable media URL and reviewed transcript are available.