OSI Model
The OSI (Open Systems Interconnection) model is a conceptual framework that splits network communication into seven layers, each responsible for one narrow job and each talking only to the layers directly above and below it. No production network stack implements all seven layers as cleanly separated code, but the model survives because it gives engineers a shared vocabulary for a question that comes up constantly: at which layer, exactly, does this problem live?
IP Addresses
An IP address is a numeric label assigned to a device on a network, used to identify it and route traffic to it — the Layer 3 concern in the OSI Model. Every design that involves more than one machine eventually depends on IP addressing working correctly: it's how a load balancer knows which backend to forward to, how a client's DNS lookup turns into something a TCP connection can actually be opened against, and how two services inside the same private network find each other at all.
DNS
DNS (Domain Name System) is the distributed, hierarchical system that translates human-readable domain names (example.com) into the IP addresses machines actually need to open a connection. It's often called "the phonebook of the internet," and the analogy is apt in one important way: almost nobody dials a raw number, and almost nothing on the internet connects to a raw IP — nearly every request starts with a name lookup you don't think about until it's slow or wrong.
Proxy vs Reverse Proxy
A proxy is any server that sits between a client and a destination server, forwarding requests on one side's behalf. "Forward proxy" and "reverse proxy" describe the exact same mechanism — an intermediary relaying traffic — but they sit on opposite sides of the relationship, and mixing them up in an interview is a fast way to signal you haven't fully internalized either one. The question that disambiguates them instantly is: whose identity is being hidden from whom?
HTTP/HTTPS
HTTP (HyperText Transfer Protocol) is the application-layer protocol — the top of the OSI Model — that almost every web and API request in a system design interview ultimately runs on. It defines a simple request/response contract: a client sends a request with a method, a path, headers, and optionally a body; a server sends back a status code, headers, and optionally a body. HTTPS is that same protocol wrapped in TLS encryption, so the content of every request and response is unreadable to anything sitting on the network path between client and server.
TCP vs UDP
TCP and UDP are the two dominant Layer 4 (Transport) protocols in the OSI Model — both sit directly on top of IP and both exist to get data from one process to another, but they make opposite bets on the same underlying tradeoff: how much reliability are you willing to pay for in latency and overhead?
Load Balancing
A load balancer distributes incoming requests across multiple servers so that no single one is overwhelmed. It's one of the most consistently reused components across system design interviews, because it's the concrete mechanism behind several ideas already introduced in this course: it's how horizontal scaling actually spreads load in practice, it's usually where failover is implemented (health checks removing a dead server from rotation), and putting one in front of a single server is the standard first fix for the most common single point of failure in a naive design.
Checksums
A checksum is a small, fixed-size value computed from a block of data and used to detect accidental corruption — a bit flipped by a noisy cable, a packet mangled in transit, a file that got truncated mid-transfer. The idea is deliberately simple: run the data through a function, keep the result alongside the data, and if the receiver recomputes the same function and gets a different answer, something changed along the way.