system-design · beginner

System Design Foundations — How Large Software Fits Together

Start here

System design is how you plan a software system made of many parts so that it:

• Solves a real user problem
• Handles growth in users and data
• Survives partial failure
• Stays understandable and operable by humans
• Fits time and money constraints

You should care because interviews, production incidents, and architecture reviews all use the same foundation vocabulary: clients, servers, data stores, caches, queues, load balancers, consistency, and trade-offs.

This is a map lesson. Later lessons go deep on each idea. Here you learn what the pieces are, why they exist, and which questions to ask first.

What you will learn

1. Define system design in plain English.
2. Name the main building blocks of internet backends.
3. Separate functional requirements from non-functional ones.
4. Estimate order-of-magnitude load (back-of-envelope).
5. Walk a simple photo-sharing design without drowning in buzzwords.
6. Recognize classic trade-offs you will meet everywhere.
7. Know what “good enough” means for a first design.

What you should know first

You can start with everyday web use:

• Apps on phones talk to servers somewhere else
• Websites store accounts and content
• Sometimes apps feel slow or break

Words you need before we begin

Simple story: a food court, not one giant kitchen

A single restaurant kitchen (one server + one database) can feed a neighborhood. A city food court adds:

• Many stalls (services)
• A directory and lines management (routing / load balancing)
• Prefixed menus on boards (caches of popular answers)
• Runners taking tickets to stalls (async queues)

The problem without intentional design

The ball of mud

One application does UI, payments, email, search, and admin tools. Any change risks everything. Scaling means buying a bigger single machine until you cannot.

Copy-paste microservices

Twenty tiny services, twenty deployment pipelines, no clear data ownership, every request fans out to twelve dependencies. Latency and incidents explode.

Ignoring non-functional needs

“It works on my laptop” with 10 users fails for 10,000. Design forces you to ask about load, failure, and data growth early.

Step-by-step explanation

Step 1 — Clarify what you are building

Write:

1. Who uses it?
2. What core actions do they take?
3. What must never go wrong (money, safety, privacy)?

Step 2 — Split functional vs non-functional requirements

Interviews and production both punish designs that only list features.

Step 3 — Sketch the request path

Most internet systems share a skeleton:

Client → DNS → Load balancer → App servers → Database
                              ↘ Cache
                              ↘ Queue → Workers

You add pieces when a measured problem appears:

• Too much read load → cache or read replicas
• Slow third-party email → queue
• One server dies → multiple instances + health checks

Step 4 — Do a back-of-envelope estimate

Rough numbers beat vibes.

Suppose:

• 10 million daily active users
• Each opens the app 5 times/day
• Each open loads a feed of 20 items

You are not seeking perfect math. You are seeking whether you need fancy machinery.

Step 5 — Choose data storage deliberately

Questions:

• Relational transactions (orders, balances)?
• Large blob files (images)? → object storage
• Search by text? → search system
• High-volume events? → log/stream

Step 6 — Plan for failure from day one (lightly)

Even a small design should answer:

• What if one app instance dies?
• What if the database primary dies?
• What if the image store is slow?

Step 7 — State trade-offs out loud

Every solid design review includes sentences like:

• “We cache feed for speed; users may see a follow change a few seconds late.”
• “We write the payment synchronously; email is async so checkout stays fast.”

Visual mental model

flowchart TB
  subgraph users [Users]
    Mobile[Mobile app]
    Web[Browser]
  end
  subgraph edge [Edge]
    DNS[DNS]
    LB[Load balancer]
  end
  subgraph core [Core services]
    API[API servers]
    Auth[Auth service]
  end
  subgraph data [Data plane]
    DB[(Primary database)]
    Cache[(Cache)]
    Obj[Object storage]
    Q[Queue]
    W[Workers]
  end
  Mobile --> DNS
  Web --> DNS
  DNS --> LB
  LB --> API
  API --> Auth
  API --> Cache
  API --> DB
  API --> Obj
  API --> Q
  Q --> W
  W --> DB

Learning question: Which box would you add first if the database CPU is hot on read-heavy feed traffic?

Caption: Start simple; add cache/queue/replicas when estimates or metrics demand them.

Complete worked example: tiny photo service v1

Starting situation

Build SnapMini:

• Upload photo
• Follow users
• Home feed of recent photos from people you follow

Constraints

• Three backend engineers
• One cloud account
• Must keep cost low
• Photos can be private

Decisions (v1)

Execution path: upload

1. Client requests upload URL or sends multipart to API.
2. API authorizes user.
3. Bytes land in object storage.
4. API inserts photo metadata row.
5. Returns photo id.

Failure behavior

• One API instance dies → balancer uses the other.
• Object storage slow → upload latency rises; metadata not committed until store succeeds (define policy).
• DB down → writes fail closed; show error.

Outcome

A boring design that can ship. Limitations: feed query may not survive 100× growth—document the scaling path (cache, fan-out on write) without building it yet.

How it works in production

Real companies encode foundations as:

• Architecture Decision Records (ADRs) for major choices
• SLIs/SLOs for reliability targets
• Runbooks for failure modes
• Progressive delivery so bad deploys hit few users first

Failure modes of “design process” itself

Trade-offs you will reuse

Compare with related concepts

Common misunderstandings

1. “System design = microservices.”

1. “More boxes means better design.”

1. “If it passes the interview, it is production-ready.”

1. “Non-functional requirements are optional polish.”

1. “We can add security later.”

Check your understanding

1. What is system design in one sentence?
2. Give two functional and two non-functional requirements for a ride-sharing app.
3. Why estimate load before adding a cache?
4. Name three building blocks in a typical web backend path.
5. State one trade-off in the SnapMini v1 design.

Practice

1. Write requirements for a URL shortener (functional + non-functional).
2. Back-of-envelope: 1M new URLs/day, 100M redirects/day—what is stressed more, write path or read path?
3. Draw a v1 design with ≤6 component types.
4. List three failures and how v1 behaves.
5. Propose what you would change at 100× traffic—and what you would not change yet.

Revision summary

• System design chooses structure under goals and constraints.
• Separate what the system does from how well.
• Start from user journeys and a simple path; add complexity with evidence.
• Use estimates to justify caches, queues, and splits.
• Always name trade-offs and failure behavior.

Glossary

Abbreviations and terminology

• API — Application Programming Interface
• DNS — Domain Name System
• HTTP — Hypertext Transfer Protocol
• p95 — 95th percentile
• ADR — Architecture Decision Record

What to learn next

1. Latency vs throughput
2. Availability
3. Scalability
4. Fault tolerance
5. Load balancing
6. Caching 101
7. Message queues

FAQ from first-time learners

Q: How detailed should a first diagram be?
A: Enough to show request flow, data stores, and failure points—not every class name.

Q: Do I need Kubernetes to design systems?
A: No. Learn concepts first. Orchestration is an implementation choice.

Q: Where do interviews stop and real jobs start?
A: Interviews reward clear requirements, estimates, and trade-offs. Jobs add stakeholders, migrations, and multi-year evolution.

Track: Distributed Systems

Next: CAP Theorem — Consistency, Availability, and Partition Tolerance

By Shubham Jain

All articles · Study paths

Shubham Jain · Learning Lab