System Design Cheat Sheet

crackr.dev

1Core Concepts

Scalability

Horizontal: Add more nodes

→

Vertical: Add more resources to a single node

→

Availability & Reliability

  • •Definitions, metrics (9s), fault tolerance vs. high availability.

99.9%

8.7 h/yr

99.99%

52 min/yr

99.999%

5 min/yr

Latency vs Throughput

  • •Latency: Time for an operation.
  • •Throughput: Operations per second.

CAP Theorem

CConsistencyAAvailabilityPPartition Tol.CPAPCA
CPex: Cassandra, MongoDB (W), HBase
APex: DynamoDB, Redis (with AP config), CouchDB
CAex: MySQL, PostgreSQL, Oracle

CP: Consistency + Partition Tolerance
AP: Availability + Partition Tolerance
CA: Consistency + Availability (not really achievable).

ACID vs BASE

ACID
  • • Atomicity
  • • Consistency
  • • Isolation
  • • Durability
BASE
  • • Basically Available
  • • Soft state
  • • Eventual consistency

TCP vs UDP

  • •TCP: connection-oriented, reliable, ordered.
  • •UDP: connectionless, fast, no delivery guarantee.

HTTP Evolution

HTTP/1.1HTTP/2MultiplexingHTTP/3 (QUIC)

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

2Load Balancing

CCCclientsnginxLoad Balancerservers

Round Robin

Least Conn

IP Hash

Weighted

L4 (Transport) vs L7 (Application)

  • •Layer 4: Network port routing
  • •Layer 7: Application-level routing, more intelligence

Health Checks

LB periodically pings servers. Unhealthy nodes are removed from the pool.

3Caching

AppCacheRedisDB1. check2. miss, read DB3. fill
  • Cache-aside: App checks cache → miss → reads DB → fills cache
  • Write-through: Write to cache + DB at the same time
  • Write-back: Write cache only → async flush to DB
  • Write-around: Write DB directly → cache on next read

Eviction Policies

  • LRU: Least Recently Used
  • LFU: Least Frequently Used
  • FIFO: First In First Out

CDN Caching

Edge locations, reduced latency for static content

Redis

Feature-rich, data structures

Memcached

Simple, multi-threaded

4Databases

SQL
  • Structured tables, fixed schema
  • ACID compliant
  • Vertical scaling (mostly)

PostgreSQL · MySQL · Oracle

NoSQL
  • Flexible schema, document/KV/graph
  • BASE, eventual consistency
  • Horizontal scaling

MongoDB · Cassandra · DynamoDB

Sharding

UsersA-HI-PQ-Zhash(user_id) → shard

Replication

masterwritesreplicareplicareplicareads →
  • Master-Slave: writes to master, reads from replicas
  • Master-Master: both accept writes, conflict resolution needed

Indexing

B-tree indexes speed up reads. Trade-off: slower writes, more storage.

Normalization vs Denormalization

  • Normalize: reduce redundancy, maintain integrity
  • Denormalize: precompute joins for read performance

List of common DB choices

PostgreSQL, MongoDB, Cassandra, DynamoDB, Redis

5Networking

DNS Resolution

Client

→

Local

→

TLD

→

Name Server

TCP vs UDP

  • TCP: Connection-oriented, reliable, ordered
  • UDP: Connectionless, fast, no delivery guarantee

WebSockets vs Long Polling

  • WebSocket: Real-time, full-duplex
  • Long Polling: Server holds request until new data
  • SSE: Server → client only stream

REST vs GraphQL vs gRPC

REST

standard verbs, stateless

GraphQL

specific data, single endpoint

gRPC

protobuf, highly efficient

6Message Queues & Streaming

ProducerQueueConsumer

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.

7API Design

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

CClientnginxAPI Gatewayuser-svcorder-svcpay-svc

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.

8Storage

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

9Microservices Patterns

Service Discovery, Find instances (Consul, etcd)
Circuit Breaker, Stop cascading failures, open/half-open/closed
Saga, Distributed transactions via compensating actions
Sidecar, Attach helper processes (logging, proxy, mesh)
CQRS, Separate read and write models for scale
Event Sourcing, Store state changes as an immutable event log
API Gateway, Single entry point for all clients

10Consistency Patterns

  • Strong: Data is immediately consistent.
  • Eventual: Data becomes consistent over time.
  • Read-your-writes: A process reads its own writes.
  • Monotonic Read: Consistent reads within a session.
  • Causal: Causally related events show up in order.

Consensus Algorithms

PaxosRaftZAB (Zookeeper)

Leader election + log replication → distributed nodes agree on a value.

11Key Numbers to Know

Latency Comparison

L1 cache
1 ns
RAM
100 ns
SSD read
~16 μs
HDD seek
~2 ms
Network RT
~150 ms

Powers of 2

2¹⁰= 1 KB
2²⁰= 1 MB
2³⁰= 1 GB
2⁴⁰= 1 TB

Common Estimation Tips

  • • 1 day ≈ 100K sec
  • • QPS = DAU × queries/user / 86,400
  • • 1 image ≈ 200 KB · 1 video min ≈ 50 MB

12System Design Interview Steps

1

Clarify requirements

Functional + non-functional

2

Estimate scale

QPS, storage, bandwidth

3

Design data model

Schema, entities, relationships

4

Define APIs

Endpoints, params, responses

5

High-level design

Draw components + data flow

6

Deep dive

Bottlenecks, trade-offs, scaling

Pro Tips

✓Don't jump into design, clarify first
✓State assumptions, validate with interviewer
✓Discuss trade-offs, not just solutions
✓Back-of-envelope math to justify choices
✓Mention monitoring, logging, alerting

The Complete System Design Cheat Sheet

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.

System Design Cheat Sheet FAQ

What is a system design cheat sheet?expand_more

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.

What topics are covered in system design interviews?expand_more

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.

What is the CAP theorem?expand_more

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).

What are the key differences between SQL and NoSQL databases?expand_more

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.

How should I approach a system design interview?expand_more

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.

What numbers should I know for system design interviews?expand_more

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.

Ready to ace your system design interview?

Practice with an AI interviewer that tests your ability to design scalable systems and articulate trade-offs in real time.

Try Crackr freearrow_forward

Continue learning

Big O Cheat Sheet

Time & space complexity reference

Blind 75

The original 75 LeetCode problems

DSA Tracker

177 problems across 16 DSA topics

Grind 75

Updated plan with custom time targets

NeetCode 150

Expanded problem set, all patterns

Algorithm Visualizers

See DSA in action

Company Questions

Real interview questions by company