System Design Fundamentals

What Is System Design?

18 min Lesson 1 of 10

What Is System Design?

System design is the process of defining the architecture, components, data flows, and interfaces of a system to satisfy a set of specified requirements. It answers the question: given what we need to build, how do we build it so that it works at scale, stays available, and can evolve over time?

The output of a system design session is not a single correct answer — it is a series of deliberate decisions and trade-offs. Two engineers can design the same product and arrive at very different architectures, each valid for different constraints. Understanding why those decisions were made is the real skill.

The Scope of System Design

System design sits at the intersection of software engineering, distributed systems, and infrastructure. It covers decisions at multiple levels:

High-level architecture — Which services exist? How do they communicate? Where does data live?
Data modeling — How is data structured, stored, and queried?
API design — What contracts do services expose to each other and to clients?
Scalability strategy — How does the system handle 10× or 1000× more traffic?
Reliability and failure handling — What happens when a server crashes or a network partition occurs?
Operational concerns — How is the system monitored, deployed, and debugged?

Key idea: System design is not about memorising patterns. It is about understanding why those patterns exist — what problem they solve, what they cost, and when to apply them.

Why System Design Matters

Consider a URL-shortening service. A working prototype fits in ~50 lines of code. But running that prototype at the scale of Bitly — 10 billion redirects per month — requires solving entirely different problems:

How do you generate unique short codes without a global lock?
Where do you store 10 billion URL mappings efficiently?
How do you serve 4,000 redirect reads per second with sub-10 ms latency?
What happens when your primary database is unreachable for 30 seconds?
How do you add analytics (click counts, geo data) without slowing down redirects?

None of these questions have a single line of code as their answer. They require architectural decisions — caching layers, database choices, replication topology, message queues — that are the domain of system design.

A prototype and a production system solve the same problem — but the production system requires architectural decisions at every level.

Functional vs Non-Functional Requirements

Every system has two categories of requirements, and confusing them is one of the most common mistakes in system design interviews and real projects alike.

Functional requirements describe what the system does — the features and behaviours visible to users and clients:

Users can paste a long URL and receive a short code.
Visiting a short URL redirects the browser to the original URL.
Links expire after 30 days unless a custom TTL is set.
Users can view click analytics for their links.

Non-functional requirements (NFRs) describe how well the system performs its job — the quality attributes that constrain the design:

Availability: 99.99% uptime (~52 minutes downtime per year).
Latency: Redirect must complete in under 20 ms at the 99th percentile.
Throughput: Handle 50,000 new URLs created per day; serve 4,000 redirects per second at peak.
Durability: A stored URL must never be lost once confirmed to the user.
Scalability: The system must handle a 10× traffic surge without manual intervention.
Security: Links cannot be guessed; users cannot overwrite each other's URLs.

Practical tip: In any design session — interview or real project — spend the first 5–10 minutes nailing down the NFRs. A system designed for 1,000 req/sec looks very different from one designed for 1,000,000 req/sec, even if the functional requirements are identical.

NFRs drive most of the interesting architectural decisions:

A latency requirement of <20 ms forces you to add a caching layer (a database round-trip alone costs 1–10 ms, and network adds more).
A durability requirement forces synchronous replication before acknowledging a write.
A scalability requirement forces stateless application servers so you can add more without coordinating state.
An availability requirement of 99.99% forces redundancy at every tier and careful handling of partial failures.

Functional requirements define features; non-functional requirements define quality constraints that shape the entire architecture.

System Design in Practice vs in Interviews

In a real project, system design is iterative. You start with a rough sketch, build a simple version, measure what actually breaks, and evolve the architecture. Twitter did not design for 500 million tweets per day on day one — they scaled incrementally and rewrote major components multiple times as bottlenecks emerged.

In a design interview, you are compressing that iterative process into 45 minutes. The interviewer is not looking for a perfect design — they are evaluating whether you can:

Ask the right clarifying questions before diving in.
Translate requirements into concrete numbers.
Make and justify architectural trade-offs.
Identify the hard problems and propose reasonable solutions.
Communicate your thinking clearly as you go.

Common pitfall: Jumping straight to a solution without clarifying requirements. Designing a system for 100 users is fundamentally different from designing for 100 million. Always establish scale and constraints first — otherwise you are solving the wrong problem.

Both contexts — real projects and interviews — share the same foundation: a clear understanding of what the system must do (functional requirements) and under what conditions (non-functional requirements). That clarity is the starting point for every good design.

What This Course Covers

Over the next ten lessons, you will learn the complete system design process from first principles:

How to gather and refine requirements (Lessons 2–3)
How to estimate scale with back-of-the-envelope calculations (Lesson 4)
Key metrics — latency, throughput, availability — and what they mean concretely (Lesson 5)
The core properties every large system must have (Lesson 6)
How to reason about trade-offs explicitly (Lesson 7)
The universal building blocks you will use in almost every design (Lesson 8)
How to translate requirements into an architecture diagram (Lesson 9)
A full hands-on project tying it all together (Lesson 10)

By the end, you will have a repeatable process for approaching any system design problem — in interviews, in architectural review meetings, and in the day-to-day decisions that shape production systems.