Prompt and context
This HTTP and security fundamentals question fits backend, platform, SRE, and infrastructure roles. The scenario is a TLS 1.3 0-RTT request reaching a gateway: early data reduces handshake waiting but can be replayed. A strong answer connects 425 semantics, business idempotency, and hop-by-hop policy.
What the interviewer evaluates
- Understanding 0-RTT's performance benefit and replay risk.
- Precise boundaries among 425, 429, 503, and 408.
- Use of idempotency keys, deduplication ledgers, and status lookup for side effects.
- Consistent early-data policy across gateways, origins, and instances.
Clarifying questions
First confirm that there is evidence of early data, whether the operation has side effects, whether the gateway preserves Early-Data, and whether the client can retry after a full handshake. Then ask about idempotency keys, uniqueness constraints, deduplication records, and shared state across instances. A GET can still have business side effects, so the method name alone is not a safety proof.
30-second answer framework
TLS 1.3 0-RTT lets a client send early data before the handshake finishes, but that data may be replayed. If a request is not proven safe to process, the server returns 425 Too Early and asks the client to retry after the handshake; the retry must not use early data again. Accept early data only for replay-safe, idempotent operations with deduplication. Gateways and origins must agree on Early-Data: 1, while monitoring retry amplification.
Step-by-step deep dive
- State the risk. 0-RTT early data is still encrypted, but an attacker may copy and replay a valid request. The core risk is duplicate side effects, not direct loss of confidentiality.
- Define 425. Return 425 when processing during the early-data phase is unsafe. A server should not emit 425 without evidence of early data; the response is not cacheable by default.
- Classify operations. Check real side effects even for reads. Payments, shipments, and quota changes should normally wait for a full handshake. If early data is accepted, require an idempotency key, uniqueness constraint, or deduplication ledger.
- Specify retry. A client that sent early data retries after a full handshake, and the retry must not be sent as early data. Bound retry count and total time.
- Keep hops consistent. A trusted intermediary may add or forward
Early-Data: 1. Gateways, load balancers, and origins need the same trust boundary; otherwise one instance may wait while another executes a side effect. - Control amplification. During overload, 425 responses and handshake retries can amplify traffic. Limit early-data size and concurrency, and monitor 425 ratio, retry rate, duplicate business keys, and handshake latency.
Model answer
I would treat Early-Data: 1 as a replay-risk signal, not as an ordinary confirmed request:
POST /payments HTTP/1.1
Early-Data: 1
Idempotency-Key: pay-123If the payment operation is not proven replay-safe, I return 425 Too Early and have the client complete the TLS handshake before retrying with the same idempotency key; the retry must not use early data again. Even for a replay-safe operation, I use a uniqueness constraint or deduplication ledger to prevent duplicate execution. 425 is not rate limiting (429), broad temporary unavailability (503), or a client timeout (408). Gateways and origins share one policy and log request ID, early-data marker, retry count, and duplicate keys so retries do not amplify overload.
Common mistakes
- Saying “0-RTT is unencrypted” → TLS still encrypts it → the risk is replay.
- Resending 0-RTT unchanged after 425 → the risk remains → retry after a full handshake.
- Returning 425 for every POST → some writes have reliable deduplication → judge side effects and evidence.
- Treating 425 as 429 → 425 handles early data, while 429 signals rate limiting → use separate backoff and alerts.
- Checking only at the gateway → origins may execute inconsistently → share trust boundaries and state.
Follow-up questions
How do you distinguish 425 from 503?
425 addresses replay risk during the early-data phase; 503 means the service is temporarily unable to handle the request. Choose 425 only when early-data evidence exists and policy requires waiting for the handshake.
Why not allow only GET?
HTTP method names do not guarantee no business side effects. Some GET requests trigger counters, prefetches, or state changes, so evaluate actual effects and deduplication.
How should a gateway pass early-data information?
A trusted intermediary may add or forward Early-Data: 1, but it must prevent untrusted clients from forging the signal and tell the origin where the marker came from and which policy applies.
How do you prove that a charge cannot happen twice?
Use the same idempotency key for a unique insert or deduplication ledger, record the final state, query before retrying, and reconcile payment events with the business order afterward.