System Design from Zero: The 12 Concepts You Need Before Your First Mock Interview
The only system design primer you need before your first mock interview, broken down into 12 simple concepts that take you from confused to competent.
You have been told to “study system design” before your first interview.
So you opened a famous textbook, tried to read about Paxos consensus on page 3, and closed the book ten minutes later, wondering if you should just stick with LeetCode.
You do not need to know everything before your first mock interview.
You need to know 12 specific concepts, well enough to use them in a sentence. This guide covers exactly those 12, in the order they tend to come up.
If you can hold a 20-minute conversation about these 12 ideas, you will not embarrass yourself in a mock. That is the whole goal of your first attempt.
1. Client-server architecture
Every system design starts here.
A client (browser, mobile app, another service) sends a request, a server processes it, and a response comes back.
Think of it like ordering food at a restaurant. You (the client) tell the waiter what you want.
The kitchen (the server) makes the food and sends it back. You do not cook the food yourself, and the kitchen does not know what you want until you ask.
Every app on your phone works the same way.
What you need to know:
The client is “dumb” in the sense that it cannot be trusted. All real validation happens on the server.
The server holds the business logic and the data.
The connection between them is usually HTTP, sometimes WebSockets for real-time, sometimes gRPC for service-to-service.
When you draw a system design diagram, the leftmost box is almost always the client. The arrow points right.
2. Load balancers
If one server can handle 1,000 requests per second and you have 10,000 requests per second coming in, you need 10 servers. The load balancer is the box that decides which server gets which request.
What you need to know:
It sits between the client and the application servers.
It distributes traffic using a strategy like round robin (rotate evenly), least connections (pick the least busy server), or hash-based (the same user always hits the same server).
It also performs health checks. If a server stops responding, the load balancer stops sending it traffic.
In interviews, you can usually draw a single “LB” box and move on. The interviewer cares that you know it exists.
3. Databases: SQL vs NoSQL
This is the first real choice you will make in any design. Pick one, justify it, move on.
A database is just a place where your app stores information that needs to last, like user accounts, posts, or orders.
The two main families work very differently.
SQL is like a neat spreadsheet with fixed columns and strict rules.
NoSQL is more like a flexible notebook where each page can look different.
SQL (PostgreSQL, MySQL):
Structured tables with fixed schemas.
Strong consistency (ACID transactions).
Use when relationships matter, when correctness matters (money, orders, accounts), or when you need complex queries.
NoSQL (MongoDB, Cassandra, DynamoDB):
Flexible schema, often key-value or document.
Scales horizontally more easily.
Eventual consistency by default.
Use for high write volume, simple lookups, or when the data model is naturally non-relational (social feed timelines, IoT events).
A safe interview answer: “I’ll use PostgreSQL for the core transactional data because I need ACID guarantees, and Redis or Cassandra for the high-throughput parts like the feed cache.”
