# System Design Basics — What It Is and How to Approach Any Question

Source: https://skills101.in/learn/system-design/system-design-basics — Skills101 free tutorial (System Design). Updated 2026-11-09.

**System design** is planning how the parts of a software system fit together so it works for **millions of users**: fast, reliable and affordable. Writing code makes a feature; system design makes it survive real traffic.

Product companies (Flipkart, Swiggy, Amazon, Google) ask system design in SDE interviews — lightly for freshers, deeply for experienced engineers. Knowing the basics also makes you a much better developer.

![A typical web system: users reach a CDN for static files and a load balancer that spreads requests across several app servers; the servers use a cache first, then a database with a primary and replicas](https://skills101.in/learn-img/system-design/request-path.svg)

## 1. Requirements first

| Type | Question | Example (a food delivery app) |
|---|---|---|
| **Functional** | what must it **do**? | search restaurants, place order, track delivery |
| **Non-functional** | how **well**? | fast (<200 ms), available 99.9%, handle 1 lakh orders/hour, secure payments |

Most design decisions come from the **non-functional** requirements.

## 2. Words you must know

| Term | Meaning |
|---|---|
| **Latency** | time for one request (ms) |
| **Throughput** | requests handled per second |
| **Availability** | % of time the system works (99.9% ≈ 8.8 hours of downtime a year) |
| **Scalability** | can it handle more users by adding resources? |
| **Consistency** | does everyone see the latest data? |
| **Fault tolerance** | does it keep working when parts fail? |
| **Bottleneck** | the slowest part that limits everything |

## 3. The building blocks

Almost every large system is made from the same parts (the next lessons cover each):

- **Load balancers** — spread traffic across servers.
- **App servers** — your code, kept stateless so you can add more.
- **Caches** — Redis/Memcached for fast repeated reads.
- **Databases** — SQL or NoSQL, with replication and sharding.
- **CDN** — serve images, videos and static files from servers near users.
- **Message queues** — Kafka/RabbitMQ for background work.
- **Object storage** — S3 for files and media.

## 4. A 6-step method for interviews

1. **Clarify requirements** (5 min) — functional features; scale (users, requests/day); read-heavy or write-heavy?
2. **Estimate** (back of the envelope) — requests/second, storage per year.
3. **API design** — the main endpoints (`POST /orders`, `GET /orders/{id}`).
4. **High-level design** — draw boxes: client → LB → services → cache → DB.
5. **Deep dive** — data model, scaling the bottleneck, caching, failure handling.
6. **Trade-offs** — say what you chose and what you gave up.

> There's no single "correct" design. Interviewers judge how you **reason**: asking questions, estimating, and explaining trade-offs clearly.

## 5. Back-of-the-envelope numbers

- 1 day ≈ **86,400 seconds** (≈ 10⁵ for quick maths).
- 1 million requests/day ≈ **12 requests/second**.
- Peak traffic is often **2–5×** the average.
- Memory is ~100× faster than SSD; SSD ~100× faster than disk.

## Common mistakes

- Jumping into drawing boxes before asking about requirements and scale.
- Designing for Google-scale when the question is a small app.
- Never mentioning trade-offs or failures.

## Quick recap

- System design = making software work at scale.
- Functional (what) vs non-functional (how well) requirements.
- Building blocks: LB, app servers, cache, DB, CDN, queues, storage.
- Interview: clarify → estimate → API → high-level → deep dive → trade-offs.


Practice quiz and free certificate: https://skills101.in/learn/system-design/system-design-basics