Skip to content
Reliability & Integration

beginner · Interactive lab

Retry + Dead Letter Queue

Choose how an order delivery responds when the warehouse API is unavailable, then inspect each attempt and its outcome.

By the end: Count retries after the initial request, and stop as soon as an attempt succeeds.

Your challenge

Start here. This lab opens with an unsafe retry policy. Repair it, test your solution, and read the trace to see why each case passes or fails.

See it happen

Follow one order, then run the system

Warehouse healthy
Slowed down so you can follow
REQUESTANSWERRETRIES USED UPOrder ProcessingWarehouse API● HEALTHYDLQIntegration LogicDECIDES: RETRY OR DLQ
Order Processing sends an order to Integration Logic, which delivers it to the Warehouse API. When every configured retry fails, Integration Logic routes the order to the DLQ.
  1. Order Processing → Integration Logic
  2. Integration Logic → Warehouse API: delivery attempt
  3. Integration Logic → DLQ: after exhaustion
STEP 1 / 6

Meet the flow

Order Processing creates an order. Integration Logic delivers it. The Warehouse API receives it. Watch the purple dot — that is one order. ORD-104 carries correlation ID COR-104 — a tracking ID that stays with the order across every retry.

Configure

Your failure policy

Set how Integration Logic handles a failing Warehouse API, then test it.

Retries

Tries after the first one. 0 means one try only; 2 means up to three tries.

Wait before each retry (backoff)

0 ms retries instantly. Simulated: nothing really waits.

When retries run out
Keep the correlation ID on every retry

The correlation ID ties every try of one order together, so it can be traced later. Graded test only; the live lab does not show it.

Learn more

Why this pattern exists

An order reaches Integration Logic, but the Warehouse API may return HTTP 503, meaning it is temporarily unavailable. A retry gives that failure another chance. Fixed backoff waits the same amount before each retry, reducing repeated pressure on the service and giving it time to recover. Whether it recovers in time depends on the outage: backoff improves the odds, it does not guarantee delivery. A dead letter queue (DLQ) keeps an order that still fails available for investigation.

Order Processing sends an order with its ID, amount, country, and correlation ID through Integration Logic to the Warehouse API. The correlation ID connects attempts for the same order. This is a common decision when a downstream API has a temporary outage. Sample cases return fixed HTTP 503 or 200 responses; no real API is called.

  • Count retries after the initial request, and stop as soon as an attempt succeeds.
  • Use fixed backoff so repeated failures do not cause immediate repeated calls.
  • Send exhausted failures to a dead letter queue without losing the correlation ID or reporting false success.

The rule this lesson applies: This lesson expects at least two retries after the initial request, at least 500 ms of fixed simulated backoff, a DLQ action after exhaustion, and a preserved correlation ID. A successful response ends the run immediately. Backoff helps only when the service recovers before the retries run out; if it stays down longer, the order still fails, and the DLQ keeps it available for investigation. The DLQ does not make delivery successful.