Chapter 1: What is System Design and Why It Matters
The Big Picture
System design is the process of defining the architecture, components, modules, interfaces, and data flow of a system to satisfy specified requirements. It's the bridge between "I need an app that does X" and actual running code.
As a C programmer, you think about functions, structs, and memory. System design zooms out: you think about servers, databases, networks, queues, caches — and how they work together at scale.
Why It Matters
- Scale: Code that works for 100 users breaks at 10 million
- Reliability: Servers crash. Networks fail. Disks die. Your system must survive.
- Cost: Bad design wastes money (over-provisioning) or loses money (downtime)
- Team velocity: Good architecture lets teams work independently
- Career: System design interviews are the gateway to senior engineering roles
What You're Actually Designing
The Core Trade-offs
System design is fundamentally about trade-offs. There's no perfect system — only systems optimized for specific constraints:
| Trade-off | Option A | Option B |
|---|---|---|
| Consistency vs Availability | Always correct data (may be slow/unavailable) | Always responds (may be stale) |
| Latency vs Throughput | Fast individual requests | High total requests/second |
| Simplicity vs Scalability | Easy to understand/maintain | Handles massive growth |
| Cost vs Performance | Cheap infrastructure | Fast response times |
| Read vs Write optimization | Fast reads (more indexes, caches) | Fast writes (fewer indexes, async) |
You already do system design in telecom! The 3GPP architecture IS a system design: AMF, SMF, UPF are services. NRF is service discovery. SBI is the API layer. The 5G SBA is a microservice architecture designed for scale and reliability. This guide teaches you the general principles behind those specific choices.
How This Guide is Structured
- Concepts (Parts I-VIII): Building blocks you combine to design systems
- Exercises (Part IX): Design real systems from scratch using those building blocks
- Framework (Part X): A repeatable approach for any design problem
The System Design Mindset
- No single "right" answer — multiple valid designs exist for any problem
- Start simple, evolve — don't design for 1 billion users on day 1
- Identify bottlenecks — where will the system break first as load grows?
- Quantify everything — "fast" means nothing; "p99 < 100ms" means something
- Design for failure — assume every component WILL fail
- System design = architecture of servers, databases, networks, and their interactions
- It's all about trade-offs — no perfect solution, only optimized ones
- Start simple, identify bottlenecks, scale incrementally
- You already know system design from 3GPP — this generalizes those principles
- Quantify requirements (QPS, latency, storage) before designing