System Design is often treated as a dark art, spoken of in hushed whispers of "high availability," "consistent hashing," and "distributed consensus." But at its core, system design is just about solving real-world scaling problems—managing how computers talk to each other, store data, and share the workload.
To make these concepts intuitive, I've applied the Richard Feynman Technique: breaking down the fundamentals of backend infrastructure (inspired by the excellent freeCodeCamp curriculum) using simple, everyday analogies.
Let's demystify the magic.
1. The Single Chef vs. The Kitchen Brigade (Client-Server & Scaling)
Every time you open a website, a Client (your browser) sends a request to a Server (a computer in a data center) asking for data, and the server returns a response.
Imagine a small local diner with a single chef in the kitchen.
When a diner (client) orders a burger, the chef (server) cooks it and sends it out. If five diners arrive, the chef stays busy. But what if a tour bus drops off 50 hungry people all at once?
The chef becomes a Single Point of Failure (SPOF). The orders pile up, wait times skyrocket, and the chef eventually collapses under stress (server crash). To solve this, we can scale:
- Vertical Scaling (Scaling Up): We buy the chef a faster stove, a sharper knife, and a larger counter. We upgraded the existing server's CPU, RAM, and storage. But there's a physical limit: a stove can only get so hot, and a single chef only has two hands.
- Horizontal Scaling (Scaling Out): We hire five more identical chefs and build duplicate cooking stations. We add more servers to our pool. If one chef gets sick (server failure), the others keep cooking. The kitchen can now handle infinite tour buses.
Vertical scaling (upgrading one server) vs. Horizontal scaling (adding more servers).
2. Ordering Dinner: Set Menu, Buffet, or Pneumatic Tube (APIs)
An API (Application Programming Interface) is the contract that defines how the client and server talk to each other. It’s the waiter who takes your order and delivers the food. There are three major patterns:
- REST (The Set Menu): Predictable and structured. The menu says: "Combo A: Burger, Fries, and Drink." You make a request to a specific URL (like
/api/burgers), and you get a predefined bundle of data back. The downside? If you only wanted the burger, you still get the fries (over-fetching). If you want dessert, you have to place a second order (under-fetching). - GraphQL (The Custom Buffet): You get a blank plate and tell the waiter: "I want exactly two slices of sushi, one slice of kiwi, and no rice." You request exactly the data fields you need, and nothing more. The server packages it up and delivers it in a single trip.
- gRPC (The Pneumatic Mail Tube): Designed for high-speed backend communications between servers. Instead of a waiter walking back and forth carrying plates (verbose JSON text data over HTTP), servers shoot compressed binary packages (Protobuf) through a high-speed pneumatic tube. It is incredibly fast and efficient, but not meant for a human client reading a standard menu.
REST (fixed combos), GraphQL (custom plates), and gRPC (high-speed binary tubes).
3. Filing Cabinets vs. Storage Crates (SQL vs. NoSQL Databases)
Servers need a place to store data. Databases generally fall into two categories:
- SQL (Relational - The Filing Cabinet): Imagine a heavy metal filing cabinet. Every drawer is labeled, and every folder has strict, color-coded dividers (tables, columns, schemas). Every customer file must contain exactly: First Name, Last Name, and Email. If you want to add "Favorite Color" tomorrow, you must open every folder in the cabinet and add that tab (schema migration). It’s perfect for banking or transactions because files are meticulously cross-referenced (relational joins).
- NoSQL (Non-Relational - The Storage Crates): Imagine throwing index cards, notebooks, and folders into plastic storage bins. One document has a phone number; another has a shopping list. There is no predefined schema (schema-less). It's extremely fast to write to and scales horizontally across multiple servers easily, but finding cross-referenced relations is slow and messy.
4. The Desk Drawer and the Local Corner Store (Caching & CDNs)
Fetching data from a database is slow. To speed things up, we use caching and Content Delivery Networks:
- Caching (The Desk Drawer): If you are an accountant and your boss asks you for the tax report every five minutes, you don't walk down to the basement archives (database) every time. You keep a copy in your desk drawer (Cache / Redis). It’s extremely fast to pull out, but if the report changes in the archives, your drawer copy is outdated (cache invalidation).
- CDNs (Neighborhood Corner Stores): If a soda factory is in Atlanta (Origin Server), shipping a single can of soda to a customer in Tokyo takes days. To solve this, the factory ships thousands of cans to corner stores in Tokyo (CDN Edge Servers). When the Tokyo customer wants a soda, they walk to the corner store and get it instantly. A CDN caches static files (images, videos, JS) on servers placed close to users globally.
Origin Server (central factory) distributing content to CDN Edge Servers (local stores) and local Caches.
5. The Traffic Cop at the Intersection (Load Balancing & Health Checks)
When you scale horizontally and have multiple servers running, how do you decide which server handles which request? Enter the Load Balancer.
Imagine a busy intersection with cars streaming in. A friendly robot traffic director (Load Balancer) stands at the center.
As cars (user requests) arrive, the robot points them to different lanes: "Car 1 goes to Server A, Car 2 goes to Server B, Car 3 goes to Server C." This is Round-Robin load balancing.
But what if Server B crashes? If the robot keeps directing traffic there, cars will pile up in a ditch. To prevent this, the load balancer runs Health Checks. Every few seconds, it whispers to the servers: "Are you okay?" If Server B doesn't respond, the robot temporarily closes that lane and routes traffic elsewhere until it recovers.
A Load Balancer directing incoming user requests to healthy backend servers.
6. The Postal System of the Internet (Networking & Protocols)
Every time your browser loads a webpage, data travels across the internet through a system that works remarkably like a postal service.
First, every device on the internet has an IP Address—its unique postal address. Just like a letter needs a "To" and "From" address to be delivered, every data packet stamped with a source IP and destination IP.
But nobody memorizes postal codes. When you type www.google.com, your browser doesn't know where that is. It asks the DNS (Domain Name System)—the internet's phone book—to look up the name and return the actual IP address (like 142.250.80.46). This happens in milliseconds, invisibly, before any data is sent.
Once we know the address, how do we deliver the data? Two protocols handle the heavy lifting:
- TCP (Transmission Control Protocol - Registered Mail): TCP is like sending a package via registered mail. Every piece is numbered, tracked, and signed for. If package #3 of 5 gets lost in transit, the sender is notified and re-sends it. The receiver assembles all pieces in the correct order before opening the box. TCP guarantees reliable, ordered delivery—perfect for web pages, emails, and file downloads where you need every single byte.
- UDP (User Datagram Protocol - Postcards): UDP is like throwing postcards out of a moving motorcycle. They're fast and lightweight, but there's no tracking number, no signature, and no guarantee they arrive (or arrive in order). If one postcard is lost, nobody re-sends it. UDP is perfect for live video calls, online gaming, and streaming—where speed matters more than perfection, and a dropped frame is better than a frozen screen.
On top of these transport protocols sits HTTP (Hypertext Transfer Protocol)—the language your browser and web servers speak. It defines the rules for "I want this webpage" (request) and "Here's the webpage" (response). It rides on top of TCP, ensuring every webpage loads completely and correctly.
DNS translates names to addresses. TCP delivers reliably like registered mail. UDP delivers fast like postcards—no guarantees.
7. The Bouncer and the VIP List (Authentication & Authorization)
Imagine a trendy nightclub with a line around the block. Before anyone gets inside, two checkpoints must be passed—and they solve two fundamentally different problems.
Authentication ("Who are you?") is the bouncer at the door. He checks your photo ID against your face. If they match, you're verified—you are who you claim to be. In the digital world, this is logging in with a username and password, scanning a fingerprint, or using a one-time code sent to your phone (multi-factor authentication).
Authorization ("What are you allowed to do?") is the hostess with the clipboard. Even after you've proven who you are, not everyone gets into the VIP lounge. The hostess checks the list: "You have a General Admission ticket—you can access the dance floor. But the VIP lounge and backstage? Those require an upgrade." In code, this is Role-Based Access Control (RBAC): an admin can delete users, an editor can publish articles, and a viewer can only read.
But there's a practical problem: if the bouncer had to check your ID every time you walked to the bar and back, the line would be insufferable. The solution? Wristbands (Tokens).
After your first ID check, the bouncer gives you a colored wristband. For the rest of the night, you just flash the wristband—no ID needed. In web systems, this wristband is a JWT (JSON Web Token). After you log in once, the server gives your browser a signed token. Every subsequent request sends this token instead of re-entering credentials. The server reads the token, verifies the signature ("is this wristband genuine?"), and checks the permissions embedded inside.
Authentication is the bouncer checking your ID. Authorization is the hostess checking the VIP list. JWT tokens are the wristbands that let you move freely.
8. The Castle Walls (Security)
If authentication and authorization are the front door, security is the entire fortress. And a well-designed fortress never relies on a single wall.
Imagine a medieval castle protecting a kingdom's treasury. The architects didn't just build one gate and hope for the best. They built layers of defense—a strategy called Defense in Depth:
- The Moat (Firewall): The outermost ring. A firewall filters incoming traffic before it even reaches your servers, blocking obviously malicious connections. Just like a moat stops a charging army from reaching the walls.
- The Drawbridge (HTTPS / TLS Encryption): All data traveling between client and server is encrypted with TLS (Transport Layer Security). Even if an attacker intercepts the data mid-transit, all they see is scrambled gibberish. The drawbridge only lowers for those with the right cryptographic keys.
- The Gate Guards (Input Validation): Guards at the gate inspect every package entering the castle. They open crates and check for weapons. In web systems, this means validating and sanitizing all user input to prevent SQL Injection (where an attacker types database commands into a login form) and Cross-Site Scripting (XSS) (where an attacker injects malicious JavaScript into a webpage that other users load).
- The Rate-Limiting Walls: Even legitimate visitors are only allowed through the gate at a controlled pace. If someone tries to batter the gate with a thousand requests per second (a brute-force attack or DDoS), the guards slow them down or lock them out. Rate limiting caps how many requests a user or IP can make in a given time window.
- The Inner Keep (Principle of Least Privilege): The treasury isn't accessible to every soldier inside the castle. Only the treasurer holds the key. In software, every component should have the minimum permissions necessary to do its job—nothing more. A web server that only needs to read from the database should never have write or delete access.
A secure system is a castle with layers: firewall (moat), HTTPS (drawbridge), input validation (gate guards), rate limiting (walls), and least privilege (inner keep).
The critical insight is that no single layer is enough. Firewalls can be bypassed. Encryption can be misconfigured. Input validation can miss edge cases. But when you stack all these defenses together, an attacker has to breach every single layer to reach the treasure. That's the power of defense in depth.
Wrapping Up
System design isn't about memorizing complex buzzwords. It's about understanding how to scale workflows, negotiate trade-offs, and design systems that are resilient to failures.
Whether you're managing a kitchen brigade of servers, deciding how to write orders with APIs, organizing databases like office filing cabinets, caching data in desk drawers, directing traffic with load balancers, navigating the postal routes of the internet, checking IDs at the nightclub door, or building castle walls to keep attackers out—the core principles remain the same.
Strip away the jargon, look for the underlying human analogy, and you'll find that system design makes perfect sense.
Originally published at https://chemacabeza.dev/writing/the-feynman-guide-to-system-design-fundamentals.
Top comments (0)