OSI Model

In this chapter, we will break down each layer of the OSI (Open Systems Interconnection) model, what each layer is responsible for, and where different networking protocols and technologies fit within the model.

When you send a request to a server, a lot happens behind the scenes before it gets there.

Your data might first travel over Wi-Fi or Ethernet, pass through multiple routers using IP protocol, move across a TCP connection, and finally arrive at the server as an HTTP request.

The OSI model gives us a simple way to understand these different responsibilities by breaking network communication into seven layers.

Each layer provides a service to the layer above it and relies on the layer below it.

Encapsulation

When an application sends data, that data moves down the stack. Each layer adds the information it needs before passing the result to the next layer.

This process is called encapsulation.

For example, an HTTP request may become a TCP segment, then an IP packet, then an Ethernet frame before it is finally transmitted as bits over a physical network.

At the receiving side, the process happens in reverse. The data moves up the stack, and each layer removes and processes the information meant for it.

Now let's go through each layer, starting from the bottom.

At the bottom of the OSI model is Layer 1: the Physical Layer.

Its job is to move raw bits from one device to another through a physical medium. That medium could be an Ethernet cable, fiber-optic cable, or wireless radio signals such as Wi-Fi.

In system design, you usually do not work directly with the Physical Layer because most of it is handled by networking hardware and cloud infrastructure.

But it is the foundation that actually carries data between devices.

Next is Layer 2: the Data Link Layer.

Its job is to move data between devices on the same local network.

At this layer, data is packaged into frames, and devices are identified using MAC addresses.

For example, when your laptop sends data to your home router over Wi-Fi or Ethernet, Layer 2 helps make sure that frame reaches the right device on the local network.

Switches mainly operate at this layer. They learn which MAC addresses are connected to which ports and use that information to forward frames efficiently.

In system design, you usually do not work directly with Layer 2, especially when using cloud infrastructure.

But understanding it helps explain how data moves inside a local network before Layer 3 takes over and routes it between different networks.

Next is Layer 3: the Network Layer.

Its job is to move data between different networks.

At this layer, data is packaged into packets, and devices are identified using IP addresses.

Suppose your browser sends a request to a server in another country. That request may pass through many different networks before it reaches the destination.

Routers mainly operate at this layer. They look at the destination IP address and decide where the packet should go next.

Layer 2 moves data within the local network. Layer 3 moves it across different networks until it reaches the destination machine.

But reaching the right machine is not enough. We still need to deliver the data to the right application running on that machine.

That is where Layer 4, the Transport Layer, comes in.

The Transport Layer is responsible for providing end-to-end communication between applications running on different machines.

The two main protocols here are TCP and UDP.

TCP

TCP is connection-oriented and reliable. It makes sure that data arrives in order. It detects missing data, and retransmits it when necessary.

UDP

UDP is much simpler. It sends data without establishing a connection or guaranteeing delivery, which reduces overhead and can make it useful for latency-sensitive workloads.

Ports

Layer 4 also introduces port numbers. An IP address identifies the destination machine, while a port identifies the application or service on that machine.

So, Layer 3 gets the packet to the right machine and Layer 4 gets the data to the right application on that machine.

Next are Layer 5, the Session Layer, and Layer 6, the Presentation Layer.

These two layers are less obvious in modern internet systems because their responsibilities are usually handled by application protocols, frameworks, and libraries.

Layer 5: Session

The Session Layer is responsible for creating, maintaining, and closing communication sessions between applications.

Layer 6: Presentation

The Presentation Layer is responsible for how data is represented and transformed before it is sent. This can include serialization, compression, encoding, and encryption.

In practice, developers rarely design systems around Layers 5 and 6 directly. Their responsibilities are often handled as part of the application stack.

And that brings us to the layer developers interact with the most: Layer 7, the Application Layer.

The Application Layer is the layer closest to the software we build.

It defines how applications communicate over the network using protocols such as HTTP, HTTPS, DNS, WebSocket, and gRPC.

For example, when your frontend calls an API, it might send an HTTP GET request.

At Layer 7, we care about what that request means and how it is structured.

System Design Components at Layer 7

Many important system design components also operate at this layer.

A reverse proxy can inspect an HTTP request before forwarding it. A Layer 7 load balancer can route traffic based on the hostname, URL path, headers, or other application-level information.

API gateways, CDNs, and many caching systems also work primarily at this layer.

Now that we have covered all seven layers, let's put everything together by following a real request from a client all the way to a server.

Suppose you open your browser and request .

Down the Browser's Stack

At the Application Layer, the browser prepares an HTTP request.

But before it can send that request, it needs to know where the server is, so it may use DNS to resolve the hostname into an IP address.

Assuming HTTPS over TCP, the browser then establishes a TCP connection to the server, typically using destination port 443.

TLS is then used to establish a secure, encrypted connection before the HTTP data is exchanged.

At the Transport Layer, the data is carried in TCP segments.

At the Network Layer, those TCP segments are placed inside IP packets containing the source and destination IP addresses.

At the Data Link Layer, each IP packet is wrapped inside a frame so it can travel across the current local network link, for example from your laptop to your Wi-Fi router.

Finally, at the Physical Layer, that frame is transmitted as electrical, optical, or radio signals.

Across the Internet

As the request travels across the internet, routers forward the IP packets from one network to another.

At each network link along the way, the IP packet may be placed inside a new Layer 2 frame appropriate for that link.

Up the Server's Stack

When the data reaches the destination server, the process works its way back up the stack.

The server receives the signals, processes the frames and IP packets, handles the TCP connection, decrypts the TLS traffic, and finally passes the HTTP request to the application.

The application processes the request and sends a response back through the same networking stack.

And that is the main idea behind the OSI model. Each layer handles a specific part of network communication, while the application ultimately sees something much simpler: a request coming in and a response going back.

One important thing to know is that the internet does not strictly follow the seven-layer OSI model.

In practice, modern networking is usually described using the TCP/IP model, which combines several OSI layers together.

The OSI model is more detailed and useful for understanding networking concepts, while the TCP/IP model is closer to how the internet actually works.

So how does the OSI model actually help?

Its biggest benefit is that it gives you a structured way to reason about where a networking problem is happening.

If a hostname does not resolve, the issue may be with DNS at the Application Layer.

If packets cannot reach the destination, the problem may be at the Network Layer, involving IP addresses, routing, or subnets.

If the server is reachable but a connection cannot be established, you may need to look at the Transport Layer, including TCP, ports, and firewalls.

If the connection works but HTTPS fails, the problem may be related to TLS.

And if the request reaches your system but goes to the wrong backend, the issue may be at Layer 7, with a reverse proxy, API gateway, or application load balancer.

You do not need to think about all seven layers every time you design a system.

But the OSI model gives you a useful mental framework for understanding how communication works, what information is available at each stage, and where things can go wrong.