You are deciding whether to front a service with connection-level (layer 4) or request-level (layer 7) proxying. How do you make that call, and what situations make layer 4 the right answer even though layer 7 is more capable?

## Start from the decisions, not the products The useful question is never "L4 or L7?" in the abstract. It is: **what does this layer have to decide, and how often?** Write the list down. If it contains anything that requires knowing what a request said, the layer must read requests. If it does not, reading requests is pure cost. Decisions that force layer 7: host, path, method or header routing; weighted traffic shifting between versions; per-request load spreading; per-request retries and timeouts; header injection and URL rewriting; response caching or compression; per-client quotas; and per-request telemetry (status, path, upstream latency) — which is often the real reason teams want it, and a perfectly good reason. Decisions that live happily at layer 4: which backend gets this connection, is that backend alive, and should this connection be admitted at all. ## Constraints that override capability Some situations settle the question before preferences enter: **The protocol is not HTTP.** PostgreSQL, MySQL, Redis, Kafka, SMTP, MQTT, custom binary RPC. A request-level proxy for HTTP simply cannot parse these, and forcing them through it means running it in a pass-through mode — which is layer 4 with extra steps. Some proxies do speak specific non-HTTP protocols at the request level; that is a per-protocol capability question, not a general one. **The proxy tier may not terminate.** If a compliance requirement, a customer contract or a key-custody boundary says the traffic must stay encrypted until it reaches the service, no layer 7 routing is possible on that path, because parsing implies decrypting. Re-encrypting upstream does not rescue it — the proxy still decrypted in the middle. Routing must then be made from connection-level facts such as the SNI name. **The budget will not take the hop.** Very high throughput per node, or a latency budget where a parsing and buffering hop is a meaningful fraction, argues for connection-level forwarding, which can approach kernel-speed copying. **Nothing per-request is being decided.** A failover front end for a database pool needs to know which primary is live. That is a connection decision. Adding an HTTP-aware tier gives it nothing to be aware of. ## Layer them rather than pick globally Mature systems rarely make one choice. A common shape: a connection-level edge that absorbs volume and handles non-HTTP listeners, then request-level proxying nearer the workload where routing and retries are decided — sometimes as a shared tier, sometimes as a per-workload sidecar. The virtue of that split is that the expensive, opinionated, frequently-reconfigured layer sits close to the team that owns it, while the cheap, stable layer takes the internet. The corresponding failure is a request-level tier deployed "for consistency" in front of traffic that never needed it: it pays parsing cost for opaque payloads, imposes header and body limits on protocols that do not have headers, and inserts a shared failure domain for no capability gained. ## Organisational cost is a real input At platform scale the choice is partly about who edits what. A shared request-level tier is a config surface that many teams change, a shared blast radius when a bad route is pushed, and a place where a bug affects everyone. That argues for keeping the shared tier as simple as the requirements allow, and pushing per-service request logic outward — to per-service proxies or sidecars — so that the change frequency of the routing rules matches the blast radius of the component holding them. ## Reversibility Moving from layer 4 to layer 7 later is usually straightforward: the addresses stay, you insert a parsing hop. Moving the other way is not, because everything built on request visibility — routing rules, weights, retries, quotas, dashboards — has to be re-homed. So it is fair to start at layer 4 when the requirement list is empty today, and fair to start at layer 7 when you can name the request-level decision you already need. What is not fair is asserting that layer 7 is "more advanced" and therefore better; the altitude that matches the decisions is the better one. ## How to answer this in an interview Name the decisions, name the constraint that could veto the choice (protocol, key custody, budget), state where you would put each layer, and say explicitly what trade you accepted — the parsing cost and the shared failure domain if you took layer 7, the loss of per-request routing, retries and telemetry if you took layer 4.