Scalability
Horizontal: Add more nodes
Vertical: Add more resources to a single node
Availability & Reliability
99.9%
8.7 h/yr
99.99%
52 min/yr
99.999%
5 min/yr
Latency vs Throughput
CAP Theorem
CP: Consistency + Partition Tolerance
AP: Availability + Partition Tolerance
CA: Consistency + Availability (not really achievable).
ACID vs BASE
TCP vs UDP
HTTP Evolution
Monolith vs Microservices vs Serverless
Monolith
Microservices
Serverless
Saga pattern · Circuit Breaker pattern · Serverless pattern
Service Discovery: find services dynamically
Sidecar: attach proxy/logging/mesh
Round Robin
Least Conn
IP Hash
Weighted
L4 (Transport) vs L7 (Application)
Health Checks
LB periodically pings servers. Unhealthy nodes are removed from the pool.
Eviction Policies
CDN Caching
Edge locations, reduced latency for static content
Redis
Feature-rich, data structures
Memcached
Simple, multi-threaded
PostgreSQL · MySQL · Oracle
MongoDB · Cassandra · DynamoDB
Sharding
Replication
Indexing
B-tree indexes speed up reads. Trade-off: slower writes, more storage.
Normalization vs Denormalization
List of common DB choices
PostgreSQL, MongoDB, Cassandra, DynamoDB, Redis
DNS Resolution
Client
Local
TLD
Name Server
TCP vs UDP
WebSockets vs Long Polling
REST vs GraphQL vs gRPC
REST
standard verbs, stateless
GraphQL
specific data, single endpoint
gRPC
protobuf, highly efficient
Kafka
Event log, high throughput
RabbitMQ
Routing, priorities
SQS
Managed, serverless
Pub/Sub
Publishers send to topics. Subscribers receive all messages. Decouples senders/receivers.
Event-Driven Architecture
Services react to events instead of direct calls. Better decoupling.
Dead Letter Queue
Handle messages that cannot be processed. Prevents blocking.
Rate Limiting
Token Bucket
Tokens refill at fixed rate
Leaky Bucket
Fixed output rate
Fixed Window
Count per time window
Sliding Window
Rolling count
API Gateway
Routing, rate limiting, auth, monitoring, SSL termination
Authentication
JWT
OAuth 2
API Key
Session
Idempotency
Ensure identical requests yield identical results. Critical for payments & retries.
Object
S3, GCS
images, videos
Block
EBS, SAN
databases
File
EFS, NAS
shared files
Blob
Azure Blob
large data
Data Lake vs Data Warehouse
Data Lake
Raw data, any format, schema-on-read, cheap
Data Warehouse
Structured, optimized for analytics, fast queries
Consensus Algorithms
Leader election + log replication → distributed nodes agree on a value.
Latency Comparison
Powers of 2
Common Estimation Tips
Clarify requirements
Functional + non-functional
Estimate scale
QPS, storage, bandwidth
Design data model
Schema, entities, relationships
Define APIs
Endpoints, params, responses
High-level design
Draw components + data flow
Deep dive
Bottlenecks, trade-offs, scaling
Pro Tips
This system design cheat sheet is a single-screen reference covering every concept you need for system design interviews. Whether you are preparing for Google, Meta, Amazon, or any top tech company, understanding distributed systems is critical to passing the system design round.
Our system design interview cheat sheet covers core concepts (scalability, CAP theorem, ACID vs BASE), load balancing, caching strategies, SQL vs NoSQL databases, networking protocols, message queues, API design, storage types, microservices patterns, consistency models, and the key numbers every engineer should know.
Unlike lengthy study guides, this system design reference is designed to fit your entire screen in one view — every concept, every pattern, every trade-off visible at a glance for quick review before your interview.
A system design cheat sheet is a quick-reference guide covering the key concepts, patterns, and trade-offs you need for system design interviews. It includes topics like load balancing, caching, databases, message queues, API design, and distributed system patterns — all in one place so you can review them at a glance.
System design interviews typically cover scalability (horizontal vs vertical), load balancing, caching strategies, database design (SQL vs NoSQL, sharding, replication), networking (HTTP, WebSockets, REST vs gRPC), message queues, API design (rate limiting, authentication), storage types, consistency patterns (CAP theorem, ACID vs BASE), and microservices architecture. This cheat sheet covers all of these.
The CAP theorem states that a distributed system can only guarantee two of three properties: Consistency (all nodes see the same data), Availability (every request gets a response), and Partition Tolerance (the system works despite network failures). Since network partitions are unavoidable, you effectively choose between CP (consistency over availability) and AP (availability over consistency).
SQL databases use structured tables with fixed schemas, support ACID transactions, and scale vertically. NoSQL databases offer flexible schemas, horizontal scaling, and come in various types (document, key-value, column-family, graph). SQL is best for complex queries and data integrity. NoSQL is best for large-scale, high-throughput applications with evolving schemas.
Follow these steps: (1) Clarify requirements — ask about functional and non-functional needs. (2) Estimate scale — calculate QPS, storage, and bandwidth. (3) Design the data model. (4) Define APIs. (5) Draw a high-level architecture. (6) Deep dive into bottlenecks and discuss trade-offs. Always state your assumptions and validate with the interviewer.
Key latencies: L1 cache ~1ns, RAM ~100ns, SSD read ~16μs, HDD seek ~2ms, cross-continent round-trip ~150ms. Powers of 2: 2^10 = 1K, 2^20 = 1M, 2^30 = 1B. Estimation shortcuts: 1 day ≈ 100K seconds, QPS = DAU × queries/user / 86,400. These help with back-of-envelope calculations.
Practice with an AI interviewer that tests your ability to design scalable systems and articulate trade-offs in real time.
Try Crackr freearrow_forward