1. Prompt and context
An HTTPS multi-tenant API reuses HTTP/2 connections across several domains. Some requests intermittently receive 421, and the team wants to rewrite it as 503 in the application controller. Judge the semantics of 421, explain SNI versus Host, and design the gateway, origin, client, and observability plan. Assume requests may pass through a CDN, reverse proxy, and service mesh.
2. What the interviewer is testing
- Whether you know that 421 means the request reached an origin unable or unwilling to provide an authoritative response for the target URI.
- Whether you can connect connection reuse, TLS SNI, request Host, scheme, and authority in one diagnostic chain.
- Whether you understand that a proxy should not invent 421 from its own routing decision and that a client should retry only on a new connection.
- Whether you can separate 421 from upstream failure, 404, 503, and certificate configuration errors instead of changing only the status code.
3. Clarifying questions before answering
- Is 421 generated by the origin, gateway, CDN, or application?
- Is the request using HTTP/2 or HTTP/3, and can one connection carry multiple authorities?
- What are the TLS SNI, HTTP Host, and selected virtual host at the final hop?
- Can the client open a new connection for the target domain, and is the method idempotent or already side-effecting?
4. A 30-second answer framework
421 means the origin believes the request was directed to the wrong connection or virtual host, such as an incompatible combination of connection certificate and target authority. Diagnose SNI, Host, scheme, authority, connection pooling, and origin routing before changing the response; do not rewrite it as 503. An origin may send 421, while a proxy should forward it rather than generate it from its own routing decision. A client may retry on a fresh connection, subject to method idempotency, request-body replay, and backoff. Correlate connection ID, SNI, authority, route, and retry outcome in logs.
5. Step-by-step deep answer
Step 1: Define the responsibility boundary
RFC 9110 defines 421 as an origin rejection because the target URI appears to have been misdirected. The cause can be an origin configuration mismatch or a request that does not fit the current connection context. The application must not map arbitrary upstream timeouts, DNS errors, or expired certificates to 421; those conditions need their own semantics.
Step 2: Reconstruct the connection context
During the TLS handshake, SNI selects a certificate and virtual host. After encryption is established, the request Host or authority selects the target. HTTP/2 can carry multiple requests on one connection, but reuse is safe only when the certificate, protocol, and server configuration permit it. Record SNI, Host, scheme, authority, ALPN, connection start time, and selected backend, then compare who owns the connection with where the request is going.
TLS SNI: api-a.example
HTTP authority: api-b.example
ALPN: h2
selected virtual host: api-a.example
result: 421 from originStep 3: Handle proxies, CDNs, and service meshes
An edge proxy should preserve the original authority, TLS-termination details, and upstream connection state, while preventing cross-tenant reuse on an incompatible upstream connection. It may forward an origin 421, but it should not generate 421 merely because its own route failed; use the proxy's 502, 503, or routing-error contract. A service-mesh pool key must include fields that affect certificate and virtual-host selection, rather than pooling only by IP and port.
Step 4: Design client retries
The specification allows a client to retry 421 on a different connection, including a fresh connection for the target origin. Before retrying, check method idempotency, request-body replayability, token validity, and whether a partial response or side effect already occurred. For POST or other side-effecting methods, use an idempotency key or confirm that execution did not happen before retrying. Limit attempts and record the reason; a fixed loop must not hide a configuration error.
Step 5: Observe, fix, and regression-test
Break down 421 by SNI, authority, virtual host, protocol version, and edge node instead of watching only a global count. Keep a redacted connection ID, route decision, certificate fingerprint, origin response, and whether the client opened a new connection. After a fix, test three paths: valid reuse must not return 421; an incompatible connection should consistently return 421; a retry on a new connection should reach the target service's final response.
6. Example of a high-quality answer
I would treat 421 as a connection-context or origin-authority mismatch, not a generic transient outage. First correlate TLS SNI, HTTP authority, certificate, ALPN, connection pool, and virtual-host routing to confirm whether the request reused an incompatible connection. The origin may return 421, while a proxy should forward it rather than invent it. A client may open a fresh connection for the target origin and retry only after checking idempotency, body replay, and idempotency keys. Measure the code by domain, protocol, node, and pool, then prove the fix with both reuse and fresh-connection regression tests.
7. Common mistakes
- Rewriting every 421 as 503 → loses connection-context evidence → preserve 421 and log SNI and authority at the gateway.
- Checking Host but not SNI → misses certificate and virtual-host reuse → record both TLS and HTTP targets.
- Letting a proxy invent 421 → violates the status-code responsibility boundary → forward origin 421 and use a clear 5xx contract for proxy routing failures.
- Retrying POST unconditionally → can duplicate writes → use an idempotency key or confirm no execution before bounded retry.
- Testing only one domain and one connection → misses HTTP/2 reuse → include cross-domain reuse, incompatible reuse, and fresh-connection tests.
8. Follow-ups and responses
How is 421 different from 503?
421 points to a mismatch between the request and the current connection or origin authority; a target-specific fresh connection may recover. 503 means the service is temporarily unable to handle the request, often because of capacity, maintenance, or a dependency. Their fixes, retry rules, and alert dimensions differ.
Can a client retry 421 on the old connection?
It should not continue using a connection that was judged unsuitable. Open a new connection for the target origin and renegotiate TLS and the protocol, while respecting backoff, body replay, and authentication state.
May a proxy return 421 when Host and SNI differ?
Not solely from the proxy's own inference. It should follow its routing-error contract or forward the request for the origin to decide. If it forwards an origin 421, preserve the source information for diagnosis.
How do you prove a pool fix did not hurt performance?
Measure valid reuse, authority-keyed pools, and rejected incompatible reuse separately. Compare 421 rate, handshake count, tail latency, connection count, and CPU. The goal is to remove incorrect reuse while keeping the added handshake cost within budget.