Backend System Design
Backend system design interviews evaluate a candidate's ability to design scalable, reliable, and maintainable systems.
Interview Structure
System design interviews typically last 45-60 minutes and cover the following areas:
- Requirements gathering - Defining functional and non-functional requirements
- High-level architecture - Components and their interactions
- Deep dives - Database design, scaling strategies, trade-offs
- Operational concerns - Monitoring, failure handling, deployment
Interview Framework
1. Clarify Requirements (5 minutes)
Functional requirements:
- Core features
- Target users
- Inputs and outputs
Non-functional requirements:
- Scale (users, requests per second)
- Latency requirements
- Consistency vs availability trade-offs
- Read vs write ratio
2. Back-of-Envelope Estimation (3-5 minutes)
Calculate the following metrics to inform design decisions:
- Requests per second
- Storage requirements
- Bandwidth needs
See Estimation for techniques and reference numbers.
3. High-Level Design (10-15 minutes)
Define the main components:
- Client/API layer
- Application servers
- Databases and caches
- Background workers
- Message queues
Include data flow between components.
4. Deep Dive (15-20 minutes)
Common deep dive topics include:
- Database schema and indexing
- API design
- Caching strategy
- Failure handling
- Scaling bottlenecks
5. Wrap Up (5 minutes)
- Design summary
- Operational concerns (monitoring, alerting)
- Future improvements
Core Concepts
Scaling Foundations
- Scaling Fundamentals - Scaling from single server to millions of users
- Estimation - Back-of-envelope calculations for system design
- Consistent Hashing - Data distribution with minimal redistribution
Architecture Patterns
- Microservices - Loosely coupled service architecture
- Message Queues - Asynchronous communication patterns
Common Interview Questions
Data Systems
- Design a URL Shortener - Hashing, databases, caching
- Design a Key-Value Store - Distributed storage, consistency, replication
- Design a Unique ID Generator - Distributed ID generation without coordination
Real-Time Systems
- Design a Rate Limiter - API protection from abuse
- Design a Chat System - WebSockets, presence, message delivery
- Design a Notification System - Push, SMS, email at scale
Content and Social
- Design a News Feed - Fan-out strategies, ranking, caching
- Design Search Autocomplete - Tries, ranking, low-latency suggestions
Infrastructure
- Design a Web Crawler - Distributed crawling, politeness, deduplication
Key Trade-offs
| Trade-off | Option A | Option B |
|---|---|---|
| SQL vs NoSQL | ACID compliance, complex queries | Horizontal scale, flexible schema |
| Consistency vs Availability | Financial data, inventory | Social feeds, analytics |
| Push vs Pull | Real-time requirements | High fan-out scenarios |
| Cache vs Database | Read-heavy, latency-critical | Write-heavy, consistency-critical |
| Sync vs Async | Simple flows, immediate feedback | Decoupling, reliability |
Preparation Guidelines
- Practice verbal explanation - System design is a collaborative discussion
- Draw diagrams - Visual communication matters
- Memorize reference numbers - Latency, throughput, and storage values
- Study production systems - Engineering blogs from Netflix, Uber, Airbnb
- Start simple, then scale - Begin with a basic design before adding complexity