Free lesson · System Design Fundamentals

OSI Model

Easy9 min readsystem-designhlddistributed-systems

Lesson 3.1 - OSI Model

The first lesson of Module 3.

The OSI (Open Systems Interconnection) model is a conceptual framework that divides network communication into seven layers. It's not how the internet literally works - the internet runs on the TCP/IP model with four layers. But OSI is how engineers talk about networking. When a colleague says "that's a Layer 7 load balancer," they mean it understands HTTP. When someone says "the problem is at Layer 4," they mean it's a TCP/UDP issue. When a network engineer says "Layer 2 connectivity," they mean the local Ethernet segment. OSI provides a shared vocabulary for describing where in the network stack a problem lives, a design decision applies, or a component operates. If you don't know the layers, you can't follow the conversation.

Interactive animation: Step through the seven layers and watch a request descend the stack.

The Seven Layers

Interactive animation: Seven layers, bottom to top: each one only talks to its neighbours.

flowchart TD
    L7["Layer 7: Application\nHTTP, gRPC, DNS, SMTP, FTP\nWhat the user's app sees"]
    L6["Layer 6: Presentation\nTLS/SSL, compression, encoding\nData format translation"]
    L5["Layer 5: Session\nConnection management\nStart/stop/manage sessions"]
    L4["Layer 4: Transport\nTCP, UDP, QUIC\nReliable or unreliable delivery"]
    L3["Layer 3: Network\nIP, ICMP, routing (BGP, OSPF)\nAddressing and path-finding"]
    L2["Layer 2: Data Link\nEthernet, Wi-Fi, MAC addresses\nNode-to-node on same network"]
    L1["Layer 1: Physical\nCables, fiber, radio, voltage\nRaw bits on the wire"]
    
    L7 --> L6 --> L5 --> L4 --> L3 --> L2 --> L1

    style L7 fill:#34d399,stroke:#10b981,color:#000
    style L4 fill:#fbbf24,stroke:#f59e0b,color:#000
    style L3 fill:#a78bfa,stroke:#8b5cf6,color:#000
    style L1 fill:#94a3b8,stroke:#64748b,color:#000

A vertical diagram showing the seven OSI layers from top to bottom, with the three most important layers for system design highlighted. Layer 7, Application - the protocols that applications use directly: HTTP for web traffic, gRPC for service communication, DNS for name resolution, SMTP for email, FTP for file transfer. This is the layer software engineers interact with most - when you design an API, choose between REST and gRPC, or configure a CDN, you're making Layer 7 decisions. Layer 6, Presentation - data format translation: TLS/SSL encryption, data compression, character encoding conversion. In modern practice, this layer is largely absorbed into Layer 7 - TLS is practically part of HTTPS, not a separate layer. Layer 5, Session - manages connections: establishing, maintaining, and tearing down communication sessions. Also largely absorbed into the application layer in modern implementations. Layer 4, Transport - the critical choice layer: TCP for reliable, ordered delivery with retransmission, or UDP for fast, unreliable delivery. QUIC (the protocol under HTTP/3) also operates here. When someone says "Layer 4 load balancer," they mean it routes based on IP and port without inspecting the application payload. Layer 3, Network - IP addressing and routing. How packets find their way across the internet from source to destination. When you discuss CDNs, anycast routing (M4.4), multi-region deployment, or VPC networking, you're reasoning about Layer 3. Layer 2, Data Link - node-to-node communication on the same local network: Ethernet frames, Wi-Fi, MAC addresses, switches. Important for network engineers; rarely relevant for system designers except when configuring VPC subnets or understanding ARP. Layer 1, Physical - raw bits on the wire: electrical signals in copper cables, light pulses in fiber optics, radio waves for Wi-Fi. The hardware layer. Relevant only when discussing data center design or physical network capacity.

The Three Layers That Matter for System Design

Interactive animation: Layer 4 is fast and blind. Layer 7 reads the request and pays for it in milliseconds.

You don't need all seven layers equally. For system design - architecture decisions, interview discussions, production debugging - three layers do 95% of the work:

Layer 7 - Application

This is where HTTP, gRPC, GraphQL, DNS, WebSocket, and SMTP live. When you design an API (M5), you're defining Layer 7 behavior. When you configure a CDN, you're caching Layer 7 responses. When you add an API gateway, you're processing Layer 7 requests.

A Layer 7 load balancer (AWS ALB, Nginx, Envoy, HAProxy in HTTP mode) understands the application protocol. It can inspect HTTP headers, route by URL path (/api/v1/* to fleet A, /api/v2/* to fleet B), read cookies for sticky sessions, terminate TLS (decrypt HTTPS, forward plain HTTP to backends), and even modify request/response headers. This is the most common load balancer type for web applications because the routing decisions usually depend on HTTP content.

Layer 7 attacks are application-level - SQL injection, cross-site scripting (XSS), API abuse. A Web Application Firewall (WAF) operates at Layer 7, inspecting HTTP requests for malicious patterns.

Layer 4 - Transport

TCP vs UDP - the choice between reliable delivery and fast delivery. This is where the transport protocol decision lives (covered in detail in 3.3).

A Layer 4 load balancer (AWS NLB, HAProxy in TCP mode) operates on IP addresses and port numbers without inspecting the application payload. It forwards TCP connections or UDP datagrams based on source/destination IP and port. It's faster than Layer 7 (no HTTP parsing overhead - just forward the packets) but blind to application content (can't route by URL, can't inspect headers, can't terminate TLS at the LB level in the traditional sense).

When to choose Layer 4 over Layer 7: when you need raw TCP/UDP forwarding at high throughput (gaming servers, database proxies, IoT ingestion), when the protocol isn't HTTP (custom TCP protocols, database wire protocols), or when the ~5-15ms overhead of Layer 7 parsing matters (ultra-low-latency trading systems).

Layer 3 - Network

IP addressing and routing - how packets traverse the internet from your server in Virginia to a user in Tokyo. When you deploy across multiple regions, configure VPC networking, set up anycast routing (M4.4), or reason about CDN edge locations, you're operating at Layer 3.

BGP (Border Gateway Protocol) operates at Layer 3 - it's the routing protocol that connects the internet's autonomous systems and enables anycast routing (M4.4). When Cloudflare announces their IP prefix from 300 locations, BGP routing at Layer 3 directs each user's traffic to the nearest location.

ICMP (the protocol behind ping and traceroute) operates at Layer 3 - useful for debugging network connectivity ("can this server reach that server?").

OSI vs TCP/IP: The Practical Reality

Interactive animation: Two models, one internet: OSI is the vocabulary, TCP/IP is the wire.

The internet doesn't actually use the OSI model - it uses the TCP/IP model with four layers:

TCP/IP Layer	Maps to OSI	What it covers
Application	OSI Layers 5, 6, 7	HTTP, DNS, TLS, gRPC, everything the app sees
Transport	OSI Layer 4	TCP, UDP, QUIC
Internet	OSI Layer 3	IP addressing, routing
Network Access	OSI Layers 1, 2	Ethernet, Wi-Fi, physical media

The TCP/IP model collapsed OSI's Layers 5, 6, and 7 into a single "Application" layer - recognizing that in practice, session management, data formatting, and application logic are handled together, not in separate protocol layers. This is why Layers 5 and 6 feel abstract and academic - in the TCP/IP implementation, they don't exist as separate layers.

In practice, engineers use OSI vocabulary on TCP/IP infrastructure. "Layer 7 load balancer" uses OSI numbering. "Layer 3 routing" uses OSI numbering. The actual protocol stack is TCP/IP. Both models are useful - OSI for precise discussion ("which layer?"), TCP/IP for understanding the implementation ("what actually happens?").

How a Request Traverses the Layers

Interactive animation: One HTTP request, wrapped layer by layer on the way down and unwrapped on the way up.

When your browser requests https://api.example.com/users/42, the data travels down the stack on the client side and up the stack on the server side:

flowchart TD
    subgraph Client["Client (browser)"]
        CL7["L7: HTTP GET /users/42\nHost: api.example.com"]
        CL6["L6: TLS encrypts the HTTP request"]
        CL4["L4: TCP segments with\nsequence numbers, checksums"]
        CL3["L3: IP packets with\nsrc: 203.0.113.42\ndst: 93.184.216.34"]
        CL2["L2: Ethernet frames with\nMAC addresses"]
        CL1["L1: Electrical signals on wire"]
    end
    
    Net["🌐 Internet\n(routers, switches, cables)"]
    
    subgraph Server["Server"]
        SL1["L1: Receives electrical signals"]
        SL2["L2: Ethernet → extract IP packet"]
        SL3["L3: IP → route to correct process"]
        SL4["L4: TCP → reassemble segments"]
        SL6["L6: TLS decrypts"]
        SL7["L7: HTTP → process request\nReturn JSON response"]
    end
    
    CL7 --> CL6 --> CL4 --> CL3 --> CL2 --> CL1
    CL1 --> Net --> SL1
    SL1 --> SL2 --> SL3 --> SL4 --> SL6 --> SL7

    style CL7 fill:#34d399,stroke:#10b981,color:#000
    style SL7 fill:#34d399,stroke:#10b981,color:#000
    style Net fill:#fbbf24,stroke:#f59e0b,color:#000

A diagram showing how a request traverses the OSI layers. On the client side, the browser constructs an HTTP GET request at Layer 7. Layer 6 encrypts it with TLS. Layer 4 breaks it into TCP segments with sequence numbers. Layer 3 wraps each segment in an IP packet with source and destination addresses. Layer 2 wraps each packet in an Ethernet frame with MAC addresses. Layer 1 converts to electrical signals and sends over the wire. The data travels across the internet through routers and switches - each router operates at Layer 3, examining the destination IP and forwarding to the next hop. On the server side, the process reverses: Layer 1 receives the electrical signals. Layer 2 extracts the IP packet from the Ethernet frame. Layer 3 routes to the correct network interface. Layer 4 reassembles TCP segments into the complete message. Layer 6 decrypts TLS. Layer 7 processes the HTTP request and generates a response. The response follows the same path in reverse. This entire journey - down 7 layers, across the network, up 7 layers - happens in milliseconds. Understanding which layer handles which concern lets you diagnose where problems occur: a DNS failure is Layer 7, a routing issue is Layer 3, a dropped connection is Layer 4, a cable failure is Layer 1.

A Brandon Story: The Layer 4 vs Layer 7 Decision

A team I'd advised needed a load balancer for their API. They initially chose an AWS NLB (Layer 4) - cheaper, faster, simpler. It worked for two months. Then they needed to split traffic: /api/v1/* to the old server fleet during a migration, and /api/v2/* to the new fleet. The NLB couldn't do it - Layer 4 sees IP and port, not URL paths. They needed Layer 7.

They migrated to an ALB (Layer 7). The ALB inspected the HTTP path and routed accordingly. During the migration period, v1 traffic went to the legacy fleet and v2 traffic went to the new fleet. After migration, all traffic went to the new fleet and the old one was decommissioned. Added latency from the ALB: ~7ms. The ability to route by path was essential for a zero-downtime migration.

Six months later, they added a second Layer 7 routing rule: requests with the header X-Beta: true were routed to a beta fleet for internal testing. This let the QA team test the next release on production infrastructure without affecting real users. Layer 7 made this trivial; Layer 4 couldn't have done it.

Lessons:

Layer 4 LBs are faster and cheaper but blind to application content. Choose them for raw TCP forwarding or when you're certain you'll never need content-based routing.
Layer 7 LBs add ~5-15ms latency but unlock path-based routing, header inspection, TLS termination, and content-based decisions.
"Which layer?" is a practical architectural decision, not academic OSI trivia. The wrong layer choice can block an entire migration strategy.
Most web applications should default to Layer 7. Choose Layer 4 only when you have a specific reason (non-HTTP protocols, ultra-low latency requirements, very high packet throughput).

Six Takeaways from This Lesson

OSI has 7 layers. For system design, three matter most: Layer 7 (application - HTTP, gRPC, DNS), Layer 4 (transport - TCP, UDP), Layer 3 (network - IP, routing).
Layer 7 is where API design, load balancing routing decisions, CDN caching, and application security (WAF) operate.
Layer 4 is where TCP vs UDP is decided. Layer 4 LBs are fast but blind to content; Layer 7 LBs are smarter but add latency.
Layer 3 is where IP addressing and routing operate. CDNs, anycast, multi-region deployment, VPC networking are Layer 3 concerns.
OSI is the vocabulary; TCP/IP is the implementation. Engineers say "Layer 7" using OSI numbering on TCP/IP infrastructure.
"Which layer?" is a practical decision - Layer 4 vs Layer 7 load balancing determines what routing decisions are possible and what migration strategies are available.

Try It

Exercise: Warmup (10 minutes). For each scenario, identify the OSI layer: a DNS lookup, a TCP handshake, an HTTP 404 response, a TLS certificate error, a cable being unplugged, a router forwarding a packet, a Wi-Fi connection dropping.

Exercise: Core (25 minutes). You're designing a multi-service architecture where /api/* goes to the API fleet, /admin/* goes to the admin fleet, and /static/* goes to a CDN origin. Which load balancer layer do you need? Draw the architecture showing where the LB sits and what routing rules it applies.

Exercise: Stretch (30 minutes). Run traceroute google.com from your terminal. Each hop is a Layer 3 router making a forwarding decision. Count the hops. Research: what does each hop represent? Can you identify your ISP's routers vs Google's?

What's Next

Lesson 3.2 covers IP addresses - how machines are identified on a network, the difference between IPv4 and IPv6, and CIDR notation for defining address ranges.

Back to System Design Fundamentals