Prompt and context
A service enables TLS 1.3 0-RTT to reduce first-byte latency on resumed connections. Some requests arrive before the handshake completes, and early data can be replayed on another connection. Explain when an API should return 425 Too Early, how a client retries, and how gateways and every service replica stay consistent.
This fits backend, networking, infrastructure, and security interviews. The test is not memorizing a status code. It is mapping transport-level replay risk to a resource’s actual side effects, then defining the boundary between 425, deferral, disabling early data, idempotency keys, and audit evidence.
What the interviewer is testing
A strong answer says 425 means the server will not risk processing a request that might be replayed. It is not a generic overload, authentication, or business-validation error. The answer distinguishes safe methods from side-effecting resources, explains why only the origin knows whether a resource tolerates early data, and covers the Early-Data header, client retry, gateway forwarding, and replica consistency. It also addresses retry storms, shared state, and irreversible effects.
Questions to clarify first
- Did the request actually arrive in early data, or does it carry a trusted
Early-Data: 1? - Does the operation mutate state, charge money, ship an order, send a message, or trigger an external side effect?
- Can the client safely retry after the handshake, with an idempotency key and deduplication store?
- Does the gateway understand 425 and Early-Data, and do all origin replicas share one policy?
- How do resumption, load, timeouts, and retry budgets affect safety and availability?
A 30-second answer
“425 is a safety rejection for an early-data request that might be replayed, not generic rate limiting. The origin chooses by resource risk: a side-effect-free or provably idempotent request may proceed or be deferred, while charging, writes, and irreversible actions should wait for the handshake and may receive 425. A client that receives 425 retries only after the handshake; gateways preserve the signal, every replica applies the same policy, and idempotency keys plus server-side deduplication protect repeated requests.”
Step-by-step answer
Step 1: Identify early data and the replay model
TLS 1.3 0-RTT lets a client send application data before the handshake completes. A completed handshake only tells you about data on that connection; it does not prove another connection did not receive the same bytes. A service therefore cannot infer uniqueness from a successful connection.
Step 2: Classify resource side effects
The origin knows the replay consequence for a resource. Reads, queries, and operations with no state change are often lower risk, but verify that billing and audit paths have no hidden writes. Creating orders, charging cards, issuing credits, changing permissions, and sending messages can execute twice; reject or defer them until the handshake completes.
Step 3: Choose deferral, rejection, or disabling 0-RTT
RFC 8470 describes rejecting early data at TLS, waiting for the handshake before processing, or returning 425 so the client retries later. All reduce replay risk; the choice depends on resource policy, memory budget, client behavior, and load. Do not use 425 as a substitute for every handshake failure.
Step 4: Emit 425 correctly
When a request arrives in early data or carries Early-Data: 1 and cannot be safely processed, the origin returns 425. It is not cacheable by default, and its payload is not a representation of an identified resource. Do not emit 425 when the client cannot retry or when the request was not early data, because recovery may be impossible.
Step 5: Define client retry boundaries
A client using early data is expected to retry after 425, but the retry must not use early data again. Preserve request semantics, cap attempts, apply backoff, and honor cancellation and deadlines. If the request itself cannot be retried safely, report failure to the caller instead of replaying indefinitely.
Step 6: Forward the signal through gateways
A gateway usually cannot know whether a particular resource accepts early data. When forwarding a request that may have been replayed, it must preserve or add Early-Data: 1; it must not remove the signal. If the origin does not support the mechanism, wait for the handshake or reject. A gateway may retry on behalf of a client only when safety is explicitly known.
Step 7: Keep replicas consistent
Every origin replica, edge node, and asynchronous worker needs the same early-data policy. If one replica defers while another charges immediately, an attacker or path difference can create duplicate effects. Share the policy version, idempotency key, deduplication record, and observable fields across replicas.
Step 8: Test retry and overload behavior
Test a complete handshake, replay to another replica, a request partially arriving before the handshake, gateway forwarding, client timeout, and server overload. Record early-data rate, 425 rate, retries, duplicate keys, duplicate effects, and queue growth. Under load, repeated 425 or 503 responses can amplify retries, so set budgets and be able to disable 0-RTT globally.
Trade-offs and boundaries
0-RTT reduces the first-byte wait on resumed connections, but requires replay analysis, consistent policy, and deduplication. A method name alone is not enough: a nominally safe method can still write billing, audit, or cache state. A resource-level policy is more reliable.
An idempotency key reduces duplicate effects but does not make every request suitable for early data. Deduplication state needs a useful retention period, cross-replica visibility, and defined behavior for key collisions, retry expiry, and storage failure. For irreversible actions, waiting for the handshake is often clearer than relying on complex compensation.
Rollout plan and evidence
Register an early-data policy for each resource: allow, defer, or 425. Add idempotency keys and deduplication for writes, have the gateway propagate Early-Data, and log connection state, policy version, and retry correlation at the origin. Run a cross-replica replay exercise and verify that orders, charges, and messages do not duplicate.
After launch, observe 425, retry, and side-effect metrics by resource and client version. If clients violate retry rules, fix the client or disable 0-RTT at the edge instead of weakening origin protection. RFC 8470 requires consistent gateway and origin handling, so release checks must cover every ingress path.
Common mistakes and follow-ups
Treating 425 as rate limiting or overload
425 targets a possibly replayed early-data request. High concurrency, an unavailable dependency, and a quota breach have different semantics and backoff behavior.
Returning 425 for every POST
The method is only a clue. Decide from the resource’s replay tolerance and reliable idempotency and deduplication. A provably idempotent write may be deferred or handled by a resource-specific policy.
Retrying 425 with 0-RTT again
RFC 8470 requires the retry after 425 to avoid early data. Otherwise the client turns the server’s protection into another replay opportunity.
Removing the Early-Data header at a gateway
Removing the signal makes the origin believe the request did not traverse early data. Preserve or add the header, verify origin support for 425, and wait for the handshake when uncertain.
How would you prove there was no duplicate charge?
Run a replay exercise with a cross-replica idempotency key, request fingerprint, and charge state machine, then verify one final business outcome per operation. Also test deduplication-store failure, a client retry after timeout, and duplicate downstream delivery; an HTTP status code alone is not proof.