System Design
Definition
System design is the process of defining the architecture, components, modules, interfaces, and data flows for a system that satisfies specified requirements. In the engineering career context, it is a key interview domain testing the ability to reason about trade-offs at scale.
Core Ideas
Design Principles
- Scalability — handle growing load by scaling horizontally (more machines) or vertically (bigger machines)
- Reliability — continue operating correctly despite failures; measured as uptime / SLA
- Availability — proportion of time the system is operational (99.9% = ~8.7h downtime/year)
- Consistency — every read sees the most recent write (strong) or eventually (eventual)
- CAP Theorem — a distributed system can guarantee at most two of: Consistency, Availability, Partition Tolerance
- Latency vs Throughput — optimise for response time OR requests-per-second; rarely both
Common Components
| Component | Examples | Purpose |
|---|---|---|
| Load Balancer | AWS ALB, NGINX | Distribute traffic across servers |
| Cache | Redis, Memcached, CDN | Reduce latency, reduce DB load |
| Database | PostgreSQL, DynamoDB | Persistent storage |
| Message Queue | SQS, Kafka | Async decoupling, backpressure |
| CDN | CloudFront, Cloudflare | Edge-cached static/dynamic content |
| Search | Elasticsearch, OpenSearch | Full-text and vector search |
Caching Strategies
- Cache-aside (lazy loading) — app checks cache, misses → fetch DB → populate cache
- Write-through — write to cache and DB simultaneously
- Write-behind — write to cache; async flush to DB (risk: data loss)
- TTL — time-based expiry; balance freshness vs hit rate
Database Design
- Normalisation vs denormalisation — 3NF for consistency; denormalise for read performance
- Sharding — horizontal partitioning across multiple DB instances (by user ID, geography)
- Replication — primary + read replicas for read scaling; failover for reliability
- SQL vs NoSQL — relational for structured/consistent data; NoSQL for flexible schema, scale
Interview Framework (RESHADED)
- Requirements — clarify functional and non-functional (scale, latency, availability)
- Estimation — back-of-envelope calculations (QPS, storage, bandwidth)
- System API — define the interface
- High-level design — draw boxes and arrows; major components
- Architecture deep-dive — focus on the hardest parts
- Data model — schema design, DB choice
- Edge cases — bottlenecks, failure modes, trade-offs
- Deep dive on bottleneck — go deep on one hard part
Interview Conduct (as distinct from framework)
A framework tells you what to cover; these are about how to behave while covering it:
- Start from the basics, then add cache and load balancer — don’t open with the complex design.
- Ask questions back, many of them: how many DAU? how many writes per day? does it need like/dislike? what’s the latency threshold? do you want code written?
- Stay at the concept level and let the interviewer drive. Say “relational vs non-relational”, not “Postgres” — commit to specifics only when asked.
- Name the trade-offs explicitly — e.g. sharding by id vs by table.
- Don’t memorize questions. Pattern-matching a rehearsed answer is visible and fails on variants.
- Don’t argue with the interviewer, even when they’re wrong. Take feedback humbly.
The asymmetry worth internalizing: the framework is table stakes, and the conduct is what actually differentiates — most candidates fail by designing too much too early and by not asking.
Relationships
- Microservices — microservices is one system design pattern
- Kubernetes — K8s is a common deployment substrate in system designs
- Cloud & AWS Infrastructure — cloud services are building blocks for system designs
- Career Development — system design is a key senior interview domain
- Legacy Systems — most real system design is applied to a system that already exists
- Designing to a Latency Budget — a response-time requirement tight enough to remove architectural options rather than rank them
References
- What Every Developer Should Learn Early On - Stack
- System Design Tips — HackBear interview-conduct tips; also references Grokking the System Design Interview