What Is System Design?

Small programs are often easy to reason about because everything happens in one process and one database. Real products outgrow that shape. Users arrive from many regions, traffic spikes without warning, machines die, data gets large, and teams need to change parts of the system independently. System design gives you a vocabulary and a process for making those choices deliberately instead of by accident.

prototype:
browser ──▶ web app ──▶ database

what changes in production:
- 10 users become 10 million users
- one server becomes a fleet
- one database becomes replicas, shards, indexes, caches, backups
- one happy path becomes retries, timeouts, deploys, outages, and abuse

The failure mode is not usually that engineers know too little tech.

• They jump to components: Redis, Kafka, Kubernetes, DynamoDB, Elasticsearch.
• They skip the question those components are supposed to answer: latency, throughput, durability, cost, correctness, or operability.
• They produce a diagram that looks sophisticated but does not solve the actual product problem.

Every design starts with requirements. Functional requirements describe what users can do. Non-functional requirements describe how well the system must do it. The second category is where most system design decisions come from.

Why the distinction matters

Suppose the feature is "users can post photos." That is not enough to design the system. A family photo app, Instagram, and a medical imaging archive all accept photo uploads, but they need very different durability, privacy, moderation, latency, and storage-cost choices.

Feature:
  upload and view photos

Consumer social app:
  p95 image view < 200 ms
  tolerate delayed counters
  optimize for CDN cache hit rate and cheap storage

Medical imaging archive:
  strong audit trail
  strict access control
  long retention
  correctness and compliance outrank feed latency

You will often use capacity estimationto turn vague words like "large scale" into numbers, and ideas like the CAP theorem to explain what happens when replicas and networks disagree.

System design is not a hunt for the perfect diagram. It is a sequence of explicit trade-offs. Every mechanism buys one property by spending another. Caches reduce read latency but introduce staleness and invalidation. Replication improves read capacity and availability but creates consistency questions. Sharding raises write capacity but makes queries and resharding harder.

Real systems show this clearly. Amazon DynamoDB lets teams tune capacity, indexes, and consistency per access pattern. Cassandra favors write availability and tunable consistency. PostgreSQL favors a strong, relational model and can scale surprisingly far before you need more exotic machinery. The right answer depends on what you promised users.

A design conversation is easier when you follow a repeatable path. You do not have to be robotic, but you should avoid wandering. Start broad, choose assumptions, sketch the system, then spend depth where risk is highest.

1. Clarify requirements
   - users, core features, out-of-scope features
   - latency, availability, consistency, durability, security

2. Back-of-the-envelope estimate
   - daily active users, requests/sec, read/write ratio
   - storage growth, bandwidth, peak traffic

3. API design
   - request/response shape and idempotency
   - pagination, auth, rate limits

4. Data model
   - entities, indexes, access patterns, retention

5. High-level architecture
   - clients, load balancers, services, stores, caches, queues

6. Deep dive
   - scale the bottleneck: feed fanout, search, upload path, hot keys

7. Identify bottlenecks and mitigations
   - failure modes, observability, backpressure, retries, capacity limits

How this sounds in an interview

• Clarify: Are we designing only posting and reading tweets, or also search, ads, DMs, and media?
• Estimate: If we have 100 million daily active users and each reads 100 posts per day, reads dominate writes.
• API: Define POST /posts and GET /timeline before choosing storage.
• Data model: Store posts by author and timeline entries by viewer because those are different access patterns.
• Deep dive: Discuss fanout-on-write vs fanout-on-read because the home timeline is likely the bottleneck.

Good system design includes the messy edges, not just the happy-path boxes. These are the places production systems usually fail.

• Scope creep:a prompt like "design YouTube" is too large. Pick the core user journey and explicitly defer the rest.
• Single points of failure: one database, one region, one queue, or one deployment pipeline can take down the whole system.
• Hotspots: one viral post, one celebrity account, or one partition key can overload an otherwise scalable design.
• Retries without idempotency: retrying payments, orders, or message sends can duplicate side effects unless the API is designed for safe repetition.
• Ignoring operations: backups, dashboards, alerts, deploy safety, and on-call runbooks are part of the system, not an afterthought.