Prompt and scope
You own payment, password-change, or order-creation APIs. The edge enables TLS 1.3 0-RTT, and a gateway may forward requests carrying Early-Data: 1. Explain when to return 425, when to proceed, and how the client retries after the handshake completes. This fits backend, platform, and API-infrastructure interviews.
RFC 8470 defines 425 as the server declining to risk processing a request that might be replayed; it is not a generic “server is busy” retry code. Assume the gateway can preserve the Early-Data signal and the service can distinguish read-only operations from side effects.
What the interviewer is testing
- Whether you separate the latency benefit of 0-RTT from replay risk instead of treating every 4xx as ordinary client input.
- Whether you can trace client, gateway, and application responsibilities for waiting, retrying, and idempotency.
- Whether you can turn RFC conditions, non-cacheability, and retry timing into a testable API policy.
A weak answer memorizes “425 means Too Early.” A strong answer makes a decision from side effects, the Early-Data signal, an idempotency key, and a bounded retry window, then explains how a bad configuration could double-charge a customer.
Clarifying questions to ask first
- Does the request carry
Early-Data: 1, or can the edge prove it arrived in early data? RFC 8470 advises against inventing 425 responses without that signal. - Does the operation create an external side effect? An order read can proceed; a charge, password change, or coupon issuance should wait for the handshake or use a strict idempotency record.
- Will the gateway retry automatically? If so, verify that it retries after the handshake and that the gateway and SDK will not each perform a retry.
- Does the client support an idempotency key and retry limit? Without them, disabling 0-RTT for the operation is safer than treating 425 as permission to retry forever.
A 30-second answer
“I first verify that the request came through TLS early data with Early-Data: 1, then classify its side effects. Read-only work can proceed; payments and password changes either wait at the gateway or receive 425. The client retries only after the handshake completes, and the service uses an idempotency key plus a uniqueness constraint to prevent duplicate execution. The gateway preserves the signal, owns one retry policy, and we monitor 425 rate, retry success, and duplicate side effects. If the chain cannot prove these conditions, I disable 0-RTT for write endpoints.”
Step-by-step solution
1. Identify the risk signal
RFC 8470 requires intermediaries to preserve the Early-Data meaning when forwarding early data. A service should consider 425 only when the request could be replayed. Returning 425 without evidence turns an ordinary network failure into a misleading security rejection.
2. Classify by side effect
Classify endpoints as read-only, safely repeatable, or unsafe to repeat. GET /orders/123 is normally read-only; issuing a one-time coupon, charging a card, or changing a password is not safely repeatable. The unsafe class should wait for a complete handshake or persist an idempotency key before any side effect.
3. Assign one retry owner
After 425, the client waits for the TLS handshake and sends the request again; the retry must not use early data. A gateway may own that retry, but the contract must say so, otherwise the gateway and SDK can both retry. Set exponential backoff, a maximum attempt count, and a visible reason for each retry.
4. Make idempotency the second defense
Require an idempotency key for writes. The service stores a unique record keyed by tenant, endpoint, and key, with at least processing, success, and retryable-failure states. A duplicate returns the original result or an explicit in-progress response. Idempotency does not replace 425: the first execution can still be replayed after the database commit and before the response reaches the client.
5. Keep gateways and instances consistent
Every instance must apply the same Early-Data policy. If a gateway is unsure that the upstream understands the signal, it waits for the handshake or rejects the early request; it must not silently forward a write to an HTTP-only service. Log a request ID, Early-Data state, 425 reason, and a hashed idempotency key, never payment contents.
6. Test the failure paths
Test requests with and without Early-Data: 1, the first retry after the handshake, gateway retries, a client timeout followed by resubmission, and two instances racing on one idempotency key. Assert that an unsafe side effect occurs once and that 425 is not cached.
The simpler alternative is disabling 0-RTT entirely. It has a clear security boundary but adds handshake latency. For a small number of endpoints where latency savings are immaterial, disabling it is safer than maintaining a cross-layer policy.
High-quality sample answer
“I would not use 425 as a general throttling error. I first check for Early-Data: 1, then ask whether the operation has a side effect. An order read can proceed; payment and password-change endpoints wait at the gateway or return 425. The client retries exactly after the handshake, with a bounded SDK policy. The service also requires an idempotency key, enforces a tenant-plus-key uniqueness constraint, and stores processing and final results so a lost response cannot cause a second charge. Gateways and instances share one policy, and we monitor 425 rate, retry success, and duplicate execution. If Early-Data cannot be propagated, I disable 0-RTT for writes instead of guessing.”
Common mistakes
- Using 425 as a 429 replacement → The trigger and client action differ → Use 425 only when early-data replay risk is present.
- Returning 425 for every request → Reads are blocked and clients may retry forever → Classify side effects and bound retries.
- Retrying in 0-RTT again → The replay window remains open → Require a completed handshake before resending.
- Putting idempotency only in the application → A gateway or another instance may execute first → Apply one policy across edge, service, and persistence.
- Logging the full payment body → Debugging exposes sensitive data → Log identifiers, reason, and a redacted key hash.
Follow-up questions and responses
What if the gateway strips the Early-Data header?
Treat it as a capability gap: the gateway must wait for the handshake or reject the early request. The application cannot infer 0-RTT from an ordinary request; fix signal propagation before enabling writes.
What if the client times out and submits again before seeing 425?
Use the same idempotency key so the second request reads the first request’s in-progress or final state. For a dangerous write without a key, return a diagnosable error and use a manual or compensating workflow; do not guess whether a charge happened.
What if retries succeed often but worsen the latency SLO?
Compare 425 rate, p95 first-success latency, duplicate side effects, and business success by endpoint and user agent. If the write benefit does not repay the latency, keep 0-RTT only for safe reads or disable it for that class of endpoint.