Every large-scale application is assembled from the same fundamental building blocks. Interviewers don't expect you to invent new technology - they want to see you select and combine the right components for a given problem. This lesson covers the toolkit you'll reach for in every design interview.
At its core, the web follows a simple model: clients send requests, servers process them, and responses flow back. But modern systems add layers between these two endpoints to handle scale, reliability, and performance.
A typical request might traverse: client → CDN → load balancer → API gateway → application server → cache → database. Each layer solves a specific problem, and understanding when each layer is needed separates strong candidates from average ones.
In interviews, always start by sketching the high-level client-server flow before diving into specifics. It shows structured thinking.
A single server has finite capacity. Load balancers distribute incoming requests across multiple servers using strategies like:
Load balancers also perform health checks, automatically removing unhealthy servers from the pool. In cloud environments, services like AWS ALB or Azure Front Door handle this transparently.
A social media feed service receives 10x more reads than writes. Which load balancing approach best ensures users consistently hit the same cache-warm server?
Caching stores frequently accessed data closer to the consumer. It exists at multiple levels:
| Layer | Example | Latency | |-------|---------|---------| | Browser cache | Static assets, API responses | ~0ms | | CDN | Images, CSS, JS files | ~10-50ms | | Application cache | Redis, Memcached | ~1-5ms | | Database cache | Query result cache | ~5-10ms |
Cache invalidation is famously one of the hardest problems in computing. Common strategies include , (update cache on every write), and (application manages cache explicitly).
Sign in to join the discussion
Phil Karlton's famous quote - "There are only two hard things in Computer Science: cache invalidation and naming things" - is so widely cited that it's practically a rite of passage in system design interviews.
Choosing the right database is one of the most impactful design decisions:
SQL databases (PostgreSQL, MySQL) offer ACID transactions, strong consistency, and structured schemas. They excel when data has clear relationships and you need complex queries with joins.
NoSQL databases come in several flavours:
You're designing a system that stores user profiles with frequently changing, semi-structured data (different fields per user type). Which database type is the strongest fit?
Not every operation needs an immediate response. Message queues (RabbitMQ, Apache Kafka, AWS SQS) decouple producers from consumers, enabling:
Kafka deserves special mention: it's not just a queue but a distributed event log, enabling event-driven architectures where multiple consumers can independently process the same stream of events.
| Aspect | Monolith | Microservices | |--------|----------|---------------| | Deployment | Single unit | Independent services | | Scaling | Scale everything together | Scale individual services | | Complexity | Simpler to start | Operational overhead | | Data | Shared database | Database per service |
Start monolith, extract microservices when needed. Most interviewers appreciate candidates who acknowledge that microservices introduce distributed system complexity (network failures, data consistency, deployment orchestration) and aren't always the right choice.
Netflix famously migrated from a monolith to microservices over several years. But Shopify - handling billions in transactions - still runs a modular monolith. What factors might make one approach better than the other for a given company?
The CAP theorem states that a distributed system can guarantee only two of three properties simultaneously:
Since network partitions are inevitable in distributed systems, the real choice is between CP (consistency over availability) and AP (availability over consistency).
You're designing a banking transaction system where incorrect balances could cause financial loss. Which CAP trade-off should you prioritise?
When you walk into a system design interview, follow this structure:
Think about a system you use daily - Instagram, Uber, or Spotify. Can you identify which building blocks from this lesson it likely uses? Where would the load balancer sit? What would be cached? Which database type fits its data model?
Next up: we'll apply these fundamentals to design a URL shortener from scratch.