System Design Basics for Interviews: Building Blocks, Trade-offs and a Step-by-Step Method

What system design interviews test

System design interviews ask you to sketch how you would build a product such as a URL shortener, a chat app or a news feed. There is no single right answer. Interviewers look at whether you can clarify requirements, break the problem down, choose sensible components, reason about trade-offs and discuss bottlenecks. They are common for experienced roles and increasingly for strong freshers at product companies (Google, Amazon). For freshers, the focus is usually low-level design (OOP and design guide) and a basic version of high-level design.

You need solid fundamentals: networks, databases and operating systems.

1. A repeatable method (use it every time)

1. Clarify requirements (3 to 5 minutes). Functional: what must the system do? Non-functional: scale, latency, availability, consistency, durability. Ask who the users are, how many, read-heavy or write-heavy, and what is out of scope.
2. Estimate scale. Users, requests per second, data size per record, storage per year, bandwidth. Rough numbers are fine; show the arithmetic.
3. Define the API. A few endpoints with inputs and outputs (POST /shorten, GET /{code}).
4. Draw the high-level design. Client, load balancer, application servers, cache, database, queue, storage.
5. Design the data model. Tables or documents, key fields, indexes, and the database choice with reasons.
6. Deep dive into the one or two hardest parts (hot keys, ordering, fan-out, ID generation).
7. Find bottlenecks and failure modes. Single points of failure, replication, rate limiting, monitoring.
8. Summarise trade-offs and say what you would improve with more time.

Think aloud throughout. Silence hides your reasoning.

2. Back-of-the-envelope numbers

• 1 day = 86,400 seconds, roughly 10^5; 1 million requests per day is about 12 requests per second
• 100 million requests per day is about 1,200 per second on average; peaks may be 2 to 5 times higher
• Storage: 500 bytes per record × 100 million records is about 50 GB
• Reading from memory is about 1,000 times faster than from an SSD; network calls cost milliseconds
• A single well-tuned database server can handle thousands of simple queries per second; a single web server can handle thousands of requests per second

Approximate is fine. State assumptions clearly ("assume 100 million monthly users").

3. Scaling basics

• Vertical scaling: a bigger machine. Simple, but has a ceiling and is a single point of failure.
• Horizontal scaling: more machines. Needs a load balancer and, ideally, stateless application servers (session data in a shared store, not in server memory).
• Availability is measured in nines (99.9% allows about 8.8 hours of downtime a year; 99.99% about 53 minutes). Achieve it with redundancy, health checks and failover.
• Latency vs throughput: how fast one request is versus how many per second.

4. Core building blocks

Load balancer: spreads traffic across servers (round robin, least connections, consistent hashing). Layer 4 balances by IP and port; layer 7 can route by URL and headers. Health checks remove failed servers.

Reverse proxy and API gateway: TLS termination, routing, authentication, rate limiting and caching in front of services.

CDN: caches static content (images, scripts, video) at servers near users, reducing latency and load.

Cache: stores frequently used data in memory (Redis, Memcached).

• Patterns: cache-aside (app checks the cache, then the database, then fills the cache), write-through, write-back
• Eviction: LRU, LFU, TTL
• Problems: stale data (invalidation is hard), cache stampede (many requests miss at once), hot keys

Databases:

• SQL: structured data, joins, transactions
• NoSQL: key-value (Redis, DynamoDB), document (MongoDB), wide-column (Cassandra), graph (Neo4j); scale horizontally, with simpler queries
• Replication: a primary handles writes and replicas serve reads and provide failover (replication lag means reads may be slightly stale)
• Sharding (partitioning): split data across servers by a key (user id, hash). Pitfalls: uneven shards, cross-shard queries, resharding. Consistent hashing reduces data movement when servers are added.
• Indexes speed up reads and slow writes

Message queues and streams (Kafka, RabbitMQ, SQS): decouple producers from consumers, absorb spikes, enable asynchronous work (sending emails, resizing images), and allow retries. Know at-least-once delivery (so make consumers idempotent), dead-letter queues and ordering within a partition.

Object storage (S3): for images, videos and backups; serve through a CDN.

Search (Elasticsearch): full-text search through an inverted index.

Rate limiting: token bucket or sliding window to protect services from abuse.

Monitoring: metrics, logs, traces and alerts (DevOps roadmap).

5. CAP, consistency and trade-offs

The CAP theorem says that when a network partition happens, a distributed system must choose consistency (everyone sees the latest write) or availability (every request gets an answer). Banking and inventory usually prefer consistency; feeds and likes usually accept eventual consistency. Also know ACID vs BASE, idempotency (safe retries), and exactly-once being hard in practice.

Each choice has a cost; always state it: "A cache gives faster reads but may serve stale data, so I would set a short TTL and invalidate on writes."

6. APIs and communication

REST (resources and HTTP verbs), gRPC (fast binary calls between services), GraphQL (clients ask for exactly the fields they need), WebSockets (two-way, real-time) and webhooks. Use pagination (prefer cursors over offsets for large, changing lists), versioning and authentication (sessions, JWT, OAuth).

7. Monolith vs microservices

A monolith is one deployable unit: simple to build, test and deploy, and a good start. Microservices split the system into independently deployable services: team independence and targeted scaling, at the cost of network calls, distributed failures, data consistency and operational complexity. Do not recommend microservices for a small product without a reason. Containers and orchestration help with the operational side (Docker and Kubernetes basics).

8. Worked example: URL shortener

Requirements: create short links, redirect quickly, 100 million new URLs per month, read-heavy (100:1), links last for years.

Estimates: 100 million per month is about 40 writes per second and about 4,000 reads per second. Storing 100 million records a month at about 500 bytes is 50 GB a month, so about 3 TB over five years.

API: POST /shorten {url} returns {code}; GET /{code} returns a 301 or 302 redirect.

Short code: use 7 characters of base62 (a-z, A-Z, 0-9): 62^7 is about 3.5 trillion combinations. Generate by encoding a unique counter or id (needs a distributed id generator or a pre-allocated range per server), or by hashing the URL and handling collisions. A counter is simple and collision-free; random codes avoid guessable sequences.

Data model: urls(code PRIMARY KEY, long_url, created_at, expires_at, user_id). A key-value store or a sharded SQL table both work; lookups are by key.

Architecture: clients, CDN or load balancer, stateless app servers, a cache (Redis) holding hot codes (most traffic goes to a small set of links), and a database with replicas. Redirects are served mostly from the cache.

Deep dives: 301 (permanent, cached by browsers, less load, no analytics) vs 302 (temporary, every click reaches you, enables analytics); custom aliases; expiry cleanup; abuse and malware checking; click analytics through a queue so redirects stay fast.

9. Worked example: chat application

Requirements: one-to-one and group messages, delivery in real time, message history, online presence.

Design: clients keep a WebSocket connection to a gateway server. A message goes to a chat service, which stores it (a write-heavy database, partitioned by chat id, such as Cassandra) and delivers it to the recipient's gateway through a pub/sub system; offline users receive a push notification and sync on reconnect. Use sequence numbers per chat for ordering, acknowledgements for delivery and read receipts, and a presence service with heartbeats and a short TTL. Discuss group fan-out, media sent through object storage, and end-to-end encryption as an extension.

10. Other practice problems

Rate limiter, news feed (fan-out on write vs on read), notification system, file storage like Dropbox, video streaming, ride sharing, an autocomplete service (a trie with caching), a distributed cache and a job portal like this site: listings, search, saved jobs and alerts.

11. Mistakes to avoid

• Jumping to boxes and technology names before clarifying requirements
• Adding Kafka, microservices and sharding to a small problem
• Ignoring failures, bottlenecks and data consistency
• Not stating trade-offs, or giving a single option with no alternatives
• Spending all the time on one component
• Memorising a diagram without understanding why each part exists

12. How to prepare

1. Learn the building blocks above until you can explain each in two minutes
2. Practise the method on one problem a week and speak aloud, drawing diagrams
3. Read engineering blogs from large companies to see real trade-offs
4. For freshers: prioritise OOP and low-level design, SQL, APIs and caching basics
5. Do mock interviews with a friend who interrupts with "what if this server dies?"

Use the technical interview checklist in your final week.