OSI Model

An interviewer asks you to design a system, then drills into 'what actually happens when the client sends a request?' If you can only say 'it goes over the internet,' you fail. The OSI model is the map that lets you answer at any layer they push on.

---

The Concept Explained

The OSI model is a seven-layer description of how data moves between two machines. Most engineers meet it as exam trivia, memorize the mnemonic, and forget it.

In a system design interview it does something specific and useful: it gives you a structured way to answer "what happens when the client sends a request?" at whatever depth the interviewer pushes to. That question is a depth probe. The interviewer already knows the answer; they are measuring how far down you can go before you run out of material.

7  Application     HTTP, gRPC, DNS, TLS payloads      your API lives here
6  Presentation    encoding, serialization, TLS       JSON, Protobuf, encryption
5  Session         connection state                   largely folded into 4 and 7 in practice
4  Transport       TCP, UDP, QUIC                     ports, reliability, congestion control
3  Network         IP, ICMP, routing                  addresses, routes, NAT
2  Data link       Ethernet, ARP, MAC                 the local segment
1  Physical        cables, radio, optics              bits on a medium

This lesson takes the design view. If you want the operational view, working through each layer with the commands to diagnose it during an outage, that is the free Networking Fundamentals course, which covers the same layers as a troubleshooting framework.

---

How It Works

Encapsulation, and why it explains overhead

Each layer wraps the one above it. A request leaving your service accumulates headers on the way down and sheds them on the way up:

your JSON body                                    { "id": 456 }
+ HTTP headers                        L7          POST /orders HTTP/1.1 ...
+ TLS record                          L6          encrypted
+ TCP header (ports, seq, flags)      L4          ~20 bytes
+ IP header (src, dst addresses)      L3          ~20 bytes
+ Ethernet frame                      L2          ~14 bytes + trailer

This is why a 100-byte API response does not cost 100 bytes on the wire, and why chatty protocols with tiny payloads waste so much: the overhead is fixed per packet regardless of how little you are sending. It is the same arithmetic behind the per-message overhead comparison in Lesson 5.1.

It also explains the MTU: an Ethernet frame typically carries 1,500 bytes, so anything larger is fragmented, and fragmentation interacts badly with tunnels and VPNs where the effective MTU is smaller.

Where each layer decides something you care about

Layer 3 answers reachability. Is there a route between these two addresses, and is one permitted to talk to the other? Private versus public addressing, NAT, VPC peering, and security groups are all layer 3 concerns (Lesson 1.2). "Can service A in region 1 reach service B in region 2" is a layer 3 question before it is anything else.

Layer 4 answers the transport contract. TCP gives ordered, reliable delivery with congestion control and connection setup cost. UDP gives none of that and none of the delay. This choice determines whether a lost packet stalls everything behind it (Lesson 1.3).

Layer 4 is also where load balancing splits: an L4 balancer distributes connections without seeing content, which is fast and blind, and is exactly why it mishandles gRPC's single multiplexed connection (Lesson 2.7).

Layer 7 answers the application contract. Methods, status codes, routing by path, authentication headers. An L7 proxy can read all of it and make decisions, which is what makes an API gateway possible (Lesson 3.1) and what makes it more expensive per request than an L4 balancer.

Tracing latency down the stack

The interview question at the end of this lesson is about latency, and the value of the model is that it turns a vague question into a checklist. Where a slow request can lose time, layer by layer:

Layer	Source of latency	Typical scale
1-2	Physical propagation, serialization	~5ms per 1,000km, unavoidable
3	Routing path, extra hops, NAT	Single-digit ms, sometimes much worse cross-region
4	TCP handshake (1 RTT), retransmission on loss, congestion window ramp	1 RTT setup; loss costs far more
6	TLS handshake (1-2 RTT), encryption cost	1-2 RTT on a new connection
7	Server processing, database, downstream calls	Usually the largest term
7	Serialization and parsing	Small, but real at high throughput (Lesson 2.3)

Two observations that make this answer strong rather than merely complete.

Connection setup dominates short requests. A new HTTPS connection costs a TCP handshake plus a TLS handshake before a single byte of your request is sent: two to three round trips. Over a 100ms RTT that is 200-300ms of pure setup for a request whose server-side work takes 5ms. This is why connection reuse, keepalive pools, and HTTP/2 multiplexing matter so much (Lesson 1.4), and why a gateway that opens a fresh upstream connection per request is quietly expensive (Lesson 3.1).

Packet loss is a layer 4 event with layer 7 symptoms. A 1% loss rate does not slow things by 1%. TCP interprets loss as congestion, shrinks its window, and waits for retransmission, so throughput collapses far out of proportion. An application that "got slow" with no code change and no CPU increase is frequently a layer 3 or 4 problem being observed at layer 7.

The model is a description, not the implementation

Worth knowing so you are not caught out: the internet does not implement OSI. It implements the TCP/IP model, which has four layers, and OSI's layers 5 and 6 have no clean equivalent.

OSI                          TCP/IP
7 Application  ┐
6 Presentation ├──────────>  Application
5 Session      ┘
4 Transport    ───────────>  Transport
3 Network      ───────────>  Internet
2 Data link    ┐
1 Physical     ┴──────────>  Link

TLS is the clearest illustration of the mismatch: it is often called layer 6 because it handles encryption, sits above TCP, and is used by layer 7 protocols, and it does not fit cleanly anywhere. QUIC is a better example still, implementing reliability and encryption together on top of UDP, which collapses layers 4, 6, and part of 7 into one protocol.

The right posture in an interview: use OSI as shared vocabulary, and do not defend it as literal truth. "TLS sits between 4 and 7, and QUIC deliberately blurs those boundaries" is a better answer than insisting on a layer number.

---

System Design Implications

• It gives structure to open-ended questions. "Walk me through what happens when a user clicks submit" is answerable in a minute or in twenty. Layering lets you go as deep as asked without losing the thread.
• It tells you where a decision belongs. Retries at layer 4 (TCP retransmission) are automatic and invisible. Retries at layer 7 (your client library) are visible and can duplicate side effects, which is exactly why idempotency exists (Lesson 2.2). Confusing them leads to designs that retry twice.
• It clarifies what each component can see. An L4 balancer cannot route on a URL path. A CDN cannot cache what it cannot read. A firewall filtering on IP cannot block a specific API call. Capability follows layer.
• It predicts where encryption changes visibility. Once TLS terminates matters: before it, intermediaries see only addresses and ports; after it, they see full requests. That single decision determines what your gateway, WAF, and observability can do (Lesson 1.7).
• It separates propagation delay from processing delay. Speed of light across an ocean is roughly 60-80ms round trip and no optimization removes it. That constraint is what drives CDNs, regional deployment, and edge compute, and recognizing which part of your latency is physics is a mark of seniority.

---

Tradeoffs and Decision Framework

Which layer to solve a problem at. Lower is faster and blinder; higher is smarter and more expensive. Blocking an abusive client by IP (layer 3) is cheap and catches innocents behind the same NAT. Blocking by API key (layer 7) is precise and requires parsing every request.

Where to terminate TLS. Terminating at the edge lets everything downstream inspect, route, cache, and log. Passing it through to the service keeps traffic encrypted end to end and blinds your infrastructure. Most designs terminate at the edge and re-encrypt internally.

L4 versus L7 load balancing. L4 is fast, protocol-agnostic, and cannot make content-based decisions or balance multiplexed connections properly. L7 gives path routing, header inspection, and per-request balancing, at higher cost per request.

How much to optimize below layer 7. Most application latency is your own code and your database. Tuning congestion control before profiling your queries is misplaced effort, and saying so demonstrates judgment.

---

Common Mistakes

Reciting layers without connecting them to decisions. Naming all seven proves memorization; explaining that gRPC's L4 balancing problem is a layer mismatch proves understanding.

Treating OSI as literally how the internet works. It is a reference model; TCP/IP is the implementation.

Assuming packet loss degrades throughput proportionally. Congestion control means small loss rates cause large throughput drops.

Ignoring connection setup cost. Two to three round trips before your request is sent, which dominates short requests on high-latency links.

Placing a capability at the wrong layer. Expecting an L4 balancer to route on paths, or a CDN to cache encrypted passthrough traffic.

Forgetting physics. Cross-continent round trips have a floor no amount of tuning removes; the answer is to move the data or the compute closer.

---