System Design for Beginners

System Design · Beginner Series

Foundations

System Design from Scratch: What Every Developer Needs to Know

A simple walkthrough of databases, load balancers, and ACID transactions — with real examples any beginner can follow.

Janani 10 min read · System Design · Beginner Friendly

When I started learning system design, every article felt like it assumed I already knew the answer. Terms like "horizontal scaling," "ACID transactions," and "load balancing" were thrown around with no explanation of why they exist.

This article is the one I wish I had. We'll build up from first principles — starting with a simple client-server setup, then layering in databases, ACID guarantees, and load balancers. By the end, you'll have a mental model you can actually use.

Who this is for: Developers who are strong at coding but new to system design. No prior architecture knowledge needed.

1. The Foundation: Client, Server, Database

Every system you'll ever design is some variation of this three-part model:

The Basic Architecture

👤 User (Browser / Mobile App)

↓ HTTP Request

⚙️ Server (Your App Logic)

↓ Database Query

🗄️ Database (Permanent Storage)

Here's what each layer does:

The User makes requests — clicking a button, submitting a form, opening a page. These travel over the internet as HTTP requests.

The Server handles logic — it checks if you're logged in, applies business rules, formats the response. Critically, the server is stateless: it doesn't remember you between requests. Every request arrives fresh.

The Database handles memory — it stores your data permanently, even if the server restarts or crashes. The server is forgetful by design; the database is the source of truth.

Why stateless servers? If servers don't store state, you can run 10 or 100 of them interchangeably. Any server can handle any request. This is the foundation of scalability.

2. SQL vs. NoSQL: The Most Common Design Decision

Once you've established you need a database, the first question is always: what kind of database? The two main camps are SQL and NoSQL.

SQL — Relational Databases

Examples: PostgreSQL, MySQL. Data lives in structured tables with rows and columns. Relationships between tables are strictly enforced.

SQL: Linked Tables

Users Table

id	name	email
1	Jana	j@x.com
2	Bob	b@x.com

⟷

Orders Table

id	user_id	item
1	1	shoes
2	1	bag

user_id in Orders references Users — the relationship is enforced by the database

NoSQL — Non-Relational Databases

Examples: MongoDB, DynamoDB, Cassandra. Data is stored flexibly — often as JSON-like documents. No rigid schema, no enforced relationships.

NoSQL: Nested Document

{
  "user_id": "1",
  "name": "Jana",
  "orders": ["shoes", "bag"]   ← nested inside the user
}

How to Choose

Pick SQL when…	Pick NoSQL when…
Data has clear relationships	Data is hierarchical or nested
You need transactions (payments)	You need massive write throughput
Schema is stable and well-defined	Schema is flexible or evolving
Complex queries and reporting	Simple key-based lookups at scale

"Start with SQL. Only reach for NoSQL when you have a specific reason — scale, flexibility, or speed at volume."

Real example: A banking app → SQL, because money transfers need strict consistency and relationships. Instagram photo metadata → NoSQL, because you're doing billions of simple lookups by photo ID with no joins needed.

3. ACID Transactions: Why Banks Trust SQL

ACID is a set of four guarantees that SQL databases make. Understanding it tells you exactly when you need SQL — and why NoSQL isn't always safe to use.

Let's use a single example throughout: transferring $100 from Jana to Bob. This requires two steps:

A Bank Transfer Transaction

Start Transaction

↓

Step 1: Deduct $100 from Jana

then

Step 2: Add $100 to Bob

↓

Commit (both succeed) OR Rollback (neither happens)

A — Atomicity: All or Nothing

If Step 2 fails (server crashes mid-transfer), Step 1 is automatically rolled back. Jana never loses money that Bob didn't receive. The transaction either completes fully, or it's as if it never happened.

C — Consistency: Rules Are Never Broken

The database enforces its own constraints before and after every transaction. If a rule says "no account balance below $0," that rule can never be violated — the transaction is rejected before it ever breaks it.

I — Isolation: Transactions Don't See Each Other

If two transfers happen simultaneously, they can't read each other's half-finished state. Each transaction runs as if it's the only one in the system. Without this, two concurrent withdrawals could both read a $100 balance and both succeed — leaving the account at -$100.

D — Durability: Committed Data Survives Crashes

Once a transaction is confirmed, the data is written to disk — not just memory. A power failure five seconds later doesn't undo your deposit.

Letter	Guarantee	What breaks without it
Atomicity	All steps succeed or none do	Jana loses $100, Bob gets nothing
Consistency	Rules are never violated	Account balance goes below $0
Isolation	Transactions don't bleed into each other	Double-spend bugs under concurrency
Durability	Committed data survives crashes	Deposit disappears after restart

Why NoSQL skips ACID: Enforcing all four guarantees requires locking and coordination — which slows things down. NoSQL trades some guarantees for speed and scale. That tradeoff is fine for Instagram photos. It is not fine for bank transfers.

4. Load Balancers: Handling the Traffic Surge

You've got your server and database. Things are going well — until your app gets popular. One server can handle maybe 200 requests per second. What happens when 1,000 arrive at once?

The Problem: One Server, Too Much Traffic

1,000 users / second

↓

⚠️ 1 Server — Overwhelmed & Crashing

↓

Database

The solution is to add more servers — but then how do users know which one to talk to? That's where a load balancer comes in.

The Solution: Load Balancer Distributes Traffic

1,000 users / second

↓

⚖️ Load Balancer

↓ distributes evenly

Server 1
~333 req/s

Server 2
~333 req/s

Server 3
~333 req/s

↓

Database

Users only ever talk to the load balancer. The individual servers are invisible. The load balancer decides — based on a routing strategy — which server gets each request.

Routing Strategies

Strategy	How it works	Best for
Round Robin	Server 1 → 2 → 3 → repeat	Servers with equal capacity
Least Connections	Send to the least-busy server	Requests with variable processing time
IP Hashing	Same user always goes to same server	When session stickiness is needed

Health Checks: Automatic Failure Recovery

Load balancers constantly ping each server: "Are you alive?" If a server goes down, traffic is automatically rerouted. Users don't even notice.

Health Check & Automatic Failover

⚖️ Load Balancer

↓ health checks every few seconds

✅ Server 1

✅ Server 2

❌ Server 3 — Down

Load balancer detects failure → routes only to Server 1 and Server 2

The Sticky Session Problem

Imagine you store a user's shopping cart in server memory. A load balancer sends your next request to a different server — and that server has no idea what's in your cart. Session lost.

The naive fix is IP hashing — same user always hits the same server. But the right fix is to not store session state in server memory at all. Store it in a shared cache like Redis, so any server can access it. That's a preview of our next topic.

Interview tip: When you suggest IP hashing, a good interviewer will push back — "what if that server goes down?" The correct follow-up is: "Actually, we should store session state in Redis so any server can serve any user."

· · ·

Putting It All Together

Here's the mental model you now have, end to end:

Full Picture

👤 Users

↓

⚖️ Load Balancer (distributes traffic, health checks)

↓

Server 1

Server 2

Server 3

↓

🗄️ Database
(SQL for transactions · NoSQL for scale)

Concept	The one-line takeaway
Client-Server Model	Server handles logic, database handles memory
SQL vs NoSQL	SQL for relationships & transactions, NoSQL for scale & flexibility
ACID	Four guarantees that make SQL safe for critical operations
Load Balancer	Distributes traffic, enables horizontal scaling, handles failures

🧠 Quick Self-Check

Before you move on, try answering these from memory:

A payment service needs to deduct from one account and add to another. Which database type — and which ACID property — is most critical here?
You're building photo storage for a social app with billions of images. SQL or NoSQL? Why?
Your app stores user sessions in server memory. A load balancer causes session loss bugs. What's the right fix?

· · ·

What's Next

You've now got the foundation of system design. The next layer to learn is caching — specifically how Redis sits between your servers and database to dramatically reduce load and speed up reads. After that: message queues, which let you decouple parts of your system so one slow component doesn't bring down everything else.

These concepts build directly on what you've just learned. The mental model is always the same: understand the problem first, then choose the tool that solves it.

Coming up in Part 2: Caching with Redis — cache-aside vs write-through, cache invalidation, and why caching is both the most powerful and most dangerous tool in your kit.