Timeouts, retries and pools · routine

Retry without making it worse

The API is mid-deploy and answers 503 twice before it recovers. Get the request through — and do it in a way that a thousand other clients could do at the same time without knocking the API back over.

How this is graded

Every request returns successfully inside 320 ms
Spreads its retries rather than lining them up
Opens at most 1 connection

The budget is measured, not chosen: it is what a configuration that solves this actually cost, plus a little room.

The client

Timeouts

connectTimeoutMsGetting a connection, handshake includedreadTimeoutMsIdle time waiting for bytes; restarts when some arrivetotalBudgetMsThe whole request, every retry and backoff included

Retries

maxAttemptsIncluding the first. 1 means no retriesjitterHow the delay is spread across clientsrespectRetryAfterWait as long as the server askedgenerateIdempotencyKeysAttach a key to non-idempotent requestshonourIdempotencyKeyRetry a non-idempotent request that carries oneretryPostTreat POST as safe to repeatretryOn429Treat 429 as worth another attempt

Pool

keepAliveReuse a connection for more than one requestmaxConnectionsHow many may be open at oncemaxPerHost…and how many to any one hostacquireTimeoutMsHow long a request waits for a free slot

Capture

Nothing has run yet. Configure the client and run it — the capture is what you will be graded on.