Quick Reference Cheatsheet

1. Latency Numbers Every Engineer Should Know

Memorize the order of magnitude — interviewers care that you know SSD is ~1000x slower than RAM, not the exact nanoseconds.

Operation	Latency	Notes
L1 cache reference	0.5 ns	Fastest memory access available
Branch mispredict	5 ns	CPU pipeline flush penalty
L2 cache reference	7 ns	~14x slower than L1
Mutex lock/unlock	25 ns	Contention makes this much worse
Main memory (RAM) reference	100 ns	~200x slower than L1
Compress 1 KB with Snappy	3 μs	Fast compression for real-time use
Read 1 MB sequentially from RAM	3 μs	RAM is fast for sequential access
SSD random read	150 μs	~1,500x slower than RAM
Read 1 MB sequentially from SSD	1 ms	SSDs excel at sequential reads
Network round trip (same datacenter)	500 μs	Assumes modern datacenter networking
HDD disk seek	10 ms	Mechanical latency — avoid random reads
Read 1 MB sequentially from HDD	20 ms	HDDs still viable for bulk sequential I/O
Network round trip (cross-continent)	150 ms	Speed of light is the bottleneck
TLS handshake	250 ms	1–2 round trips depending on version
DNS lookup (uncached)	~50 ms	Varies widely; caching helps enormously
TCP connection setup (3-way handshake)	~1.5x RTT	One and a half round trips

Key ratios to remember: RAM is ~1,000x faster than SSD. SSD is ~100x faster than HDD. Network within a datacenter is ~300x faster than cross-continent.

2. Database Selection Matrix

Use Case	Recommended DB	Reasoning
Transactions, complex joins	PostgreSQL / MySQL	ACID guarantees, mature tooling, SQL standard
Flexible schema, rapid dev	MongoDB / DynamoDB	Document model maps to application objects, schema-on-read
Session store, caching, leaderboards	Redis / Memcached	Sub-ms latency, in-memory, simple key-value operations
Social networks, recommendations	Neo4j / Amazon Neptune	Native graph traversal, relationship-first data model
Metrics, IoT, monitoring	TimescaleDB / InfluxDB	Optimized for time-ordered writes and range queries
Full-text search, log analytics	Elasticsearch / OpenSearch	Inverted index, fuzzy matching, aggregation pipelines
Wide-column, massive scale	Cassandra / ScyllaDB	Linear horizontal scaling, tunable consistency
Embedded / edge devices	SQLite	Zero-config, single-file, surprisingly powerful
Multi-model (graph + doc + KV)	ArangoDB / SurrealDB	One engine for multiple access patterns

No database is “best.” The right choice depends on your access patterns, consistency requirements, team expertise, and operational budget. Picking a DB because it is trendy is a career-limiting move.

3. Caching Strategy Decision Tree

Pattern	How It Works	When to Use	Trade-off
Cache-Aside	App checks cache first; on miss, reads DB, then populates cache	General-purpose, read-heavy workloads	Possible stale data; app must manage cache logic
Read-Through	Cache itself fetches from DB on miss	When you want transparent caching	Cache library must support DB integration
Write-Through	Write to cache and DB synchronously	When you cannot tolerate stale reads	Higher write latency (two writes per operation)
Write-Behind	Write to cache immediately; async flush to DB	Write-heavy workloads needing low latency	Risk of data loss if cache node crashes before flush
Refresh-Ahead	Proactively refresh entries before TTL expires	Predictable access patterns with low-latency needs	Wasted resources if prediction is wrong

Cache Invalidation — The Two Hard Problems

As Phil Karlton said: “There are only two hard things in Computer Science: cache invalidation and naming things.”Strategies for invalidation:

TTL (Time-To-Live): Simple, but stale data during the window.
Event-driven invalidation: Publish a cache-bust event on write. Accurate but adds coupling.
Version keys: Append a version number to cache keys; bump version on write.
Lease-based: Cache entry holds a lease; writer must acquire lease before updating.

Rule of thumb: If your data changes less than once per minute, TTL is usually fine. If it changes per-second, use event-driven invalidation.

4. API Style Comparison

Dimension	REST	gRPC	GraphQL	WebSocket
Protocol	HTTP/1.1 or HTTP/2	HTTP/2 (always)	HTTP/1.1 or HTTP/2	TCP (upgraded from HTTP)
Payload format	JSON (typically)	Protocol Buffers (binary)	JSON	Any (text or binary frames)
Best for	Public APIs, CRUD	Internal microservices, low-latency	Mobile/frontend with varied data needs	Real-time bidirectional communication
Streaming	Not native (SSE possible)	Bidirectional streaming built-in	Subscriptions via WebSocket	Full-duplex by design
Tooling	Excellent (Postman, curl)	Growing (grpcurl, BloomRPC)	Good (GraphiQL, Apollo)	Moderate (wscat)
Schema/Contract	OpenAPI / Swagger	.proto files (strict)	SDL (strongly typed)	No built-in contract
Overhead	Moderate (text-based)	Low (binary, multiplexed)	Moderate (single endpoint)	Low after handshake
Cacheability	Excellent (HTTP caching)	Hard (binary, no native HTTP cache)	Hard (POST requests)	Not applicable
Browser support	Native	Requires grpc-web proxy	Native	Native

Default to REST for public APIs. Use gRPC for internal service-to-service communication where latency matters. Use GraphQL when clients have highly variable data needs. Use WebSockets only when you truly need server-push or bidirectional streaming.

5. Deployment Strategy Matrix

Strategy	Risk Level	Downtime	Infra Cost	Complexity	Rollback Speed	Best For
Rolling	Medium	Zero	Low	Low	Slow	Stateless services, general use
Blue-Green	Low	Zero	High (2x)	Medium	Instant	Critical services needing instant rollback
Canary	Low	Zero	Medium	High	Fast	High-traffic services, gradual validation
Shadow	Very Low	Zero	High	Very High	N/A (no live traffic affected)	Testing new versions with real traffic patterns
Recreate	High	Yes	Low	Low	Slow	Dev/staging, or when in-place upgrade is required
A/B Testing	Low	Zero	Medium	High	Fast	Feature experiments, UX testing

Canary + feature flags is the gold standard for production deployments at scale. Roll out to 1% of traffic, monitor error rates and latency, then gradually increase.

6. Authentication Method Decision Matrix

Method	Use Case	Stateful?	Revocation	Complexity	Scalability
Session	Traditional web apps	Yes	Easy (delete from store)	Low	Requires shared store (Redis)
JWT	Stateless APIs, microservices	No	Hard (must wait for expiry or use blocklist)	Medium	Excellent (no central store)
OAuth 2.0	Third-party access, SSO	Depends	Moderate (token revocation endpoint)	High	Good
API Key	Server-to-server, developer APIs	Yes	Easy (delete key)	Low	Good
mTLS	Zero-trust service mesh, internal	No	Hard (CRL/OCSP)	Very High	Excellent
SAML	Enterprise SSO	Yes	Moderate	High	Good
Passkeys/WebAuthn	Passwordless consumer auth	No	Easy (remove credential)	Medium	Excellent

Never roll your own auth for production systems. Use battle-tested libraries and standards. The most common security breaches come from custom authentication implementations.

7. Message Queue Comparison

Dimension	Kafka	RabbitMQ	SQS	Redis Streams
Throughput	Millions/sec	Tens of thousands/sec	Nearly unlimited (managed)	Hundreds of thousands/sec
Ordering	Per-partition	Per-queue (with caveats)	Best-effort (FIFO available)	Per-stream
Persistence	Disk (configurable retention)	Optional (disk or memory)	Managed (AWS handles it)	AOF / RDB snapshots
Delivery	At-least-once / exactly-once	At-least-once / at-most-once	At-least-once / exactly-once (FIFO)	At-least-once
Consumer model	Pull-based consumer groups	Push-based (with prefetch)	Pull-based polling	Consumer groups (pull)
Best for	Event streaming, log aggregation, high-throughput pipelines	Task queues, RPC, complex routing	Serverless, AWS-native decoupling	Lightweight streaming, when you already have Redis
Operational cost	High (ZooKeeper/KRaft, brokers)	Medium (Erlang runtime)	Zero (fully managed)	Low (add-on to existing Redis)

When to use a message queue vs direct API calls

Use a message queue when:

The downstream service can be temporarily unavailable
You need to decouple producers from consumers
Work can be processed asynchronously
You need to buffer traffic spikes
Multiple consumers need the same event

Use a direct API call when:

You need a synchronous response
The operation must complete before proceeding
Latency is critical (queues add latency)
The system is simple enough that a queue adds unjustified complexity

8. Container Orchestration Quick Reference

Core Kubernetes Objects

Object	What It Does
Pod	Smallest deployable unit; one or more containers sharing network/storage
Deployment	Manages ReplicaSets; handles rolling updates and rollbacks
ReplicaSet	Ensures a specified number of pod replicas are running at all times
Service	Stable network endpoint that routes traffic to a set of pods
Ingress	HTTP/HTTPS routing rules from external traffic to internal services
ConfigMap	Injects non-sensitive configuration data into pods as env vars or files
Secret	Stores sensitive data (tokens, passwords) with base64 encoding
StatefulSet	Like Deployment but with stable pod identity and persistent storage
DaemonSet	Runs exactly one pod per node (logging agents, monitoring)
Job / CronJob	Runs a task to completion once (Job) or on a schedule (CronJob)
Namespace	Virtual cluster for isolating resources within the same physical cluster
PersistentVolume (PV)	A piece of storage provisioned in the cluster
PersistentVolumeClaim (PVC)	A request for storage by a pod
HorizontalPodAutoscaler	Scales pod count based on CPU, memory, or custom metrics
NetworkPolicy	Firewall rules controlling pod-to-pod and external traffic

Mental model: Deployments manage ReplicaSets, which manage Pods. Services give Pods a stable DNS name. Ingress gives Services an external URL. Everything else is configuration, storage, or scheduling.

9. Common HTTP Status Codes for Engineers

Success (2xx)

Code	Name	When to Use
`200`	OK	Standard success for GET, PUT, PATCH
`201`	Created	Resource successfully created (POST)
`202`	Accepted	Request accepted for async processing (not yet completed)
`204`	No Content	Success with no response body (DELETE, PUT with no return)

Redirection (3xx)

Code	Name	When to Use
`301`	Moved Permanently	Resource URL has permanently changed (SEO-safe redirect)
`302`	Found	Temporary redirect (use 307 for strict method preservation)
`304`	Not Modified	Client cache is still valid (conditional GET)

Client Error (4xx)

Code	Name	When to Use
`400`	Bad Request	Malformed syntax, invalid parameters, validation failure
`401`	Unauthorized	Missing or invalid authentication credentials
`403`	Forbidden	Authenticated but not authorized for this resource
`404`	Not Found	Resource does not exist at this URI
`405`	Method Not Allowed	HTTP method not supported on this endpoint
`409`	Conflict	State conflict (duplicate resource, concurrent edit)
`422`	Unprocessable Entity	Syntactically valid but semantically incorrect
`429`	Too Many Requests	Rate limit exceeded — include `Retry-After` header

Server Error (5xx)

Code	Name	When to Use
`500`	Internal Server Error	Unhandled exception — generic server failure
`502`	Bad Gateway	Upstream service returned an invalid response
`503`	Service Unavailable	Server is overloaded or in maintenance — temporary
`504`	Gateway Timeout	Upstream service did not respond in time

401 vs 403: 401 means “I don’t know who you are” (authentication). 403 means “I know who you are, but you can’t do this” (authorization). Getting this wrong confuses every frontend developer on the team.

10. The “Nines” Table — Availability Reference

Availability	Common Name	Downtime / Year	Downtime / Month	Downtime / Week
99%	Two nines	3.65 days	7.31 hours	1.68 hours
99.9%	Three nines	8.77 hours	43.83 minutes	10.08 minutes
99.95%	Three and a half	4.38 hours	21.92 minutes	5.04 minutes
99.99%	Four nines	52.60 minutes	4.38 minutes	1.01 minutes
99.999%	Five nines	5.26 minutes	26.30 seconds	6.05 seconds
99.9999%	Six nines	31.56 seconds	2.63 seconds	0.60 seconds

How to reason about SLAs in system design interviews

Combining availability: If Service A (99.9%) depends on Service B (99.9%), the combined availability is at best 99.9% x 99.9% = 99.8%. Each dependency in the critical path multiplies downtime.Improving availability:

Redundancy: Run multiple replicas across availability zones.
Eliminate single points of failure: Every component in the critical path needs failover.
Graceful degradation: Serve cached/stale data instead of failing entirely.
Health checks + auto-restart: Detect and recover from failures automatically.

Rule of thumb: Most production web apps target three nines (99.9%). Banks and telecom target four to five nines. Achieving five nines requires automated everything — humans are too slow.

11. Back-of-Envelope Estimation Cheat Sheet

Powers of 2 — Capacity Reference

Power	Exact Value	Approximate Size
2^10	1,024	~1 Thousand (1 KB)
2^20	1,048,576	~1 Million (1 MB)
2^30	1,073,741,824	~1 Billion (1 GB)
2^40	1,099,511,627,776	~1 Trillion (1 TB)
2^50		~1 Petabyte (1 PB)

Common Estimation Building Blocks

Metric	Value
Seconds in a day	~86,400 (~10^5)
Seconds in a month	~2.6 million (~2.5 x 10^6)
Seconds in a year	~31.5 million (~3 x 10^7)
Average size of a tweet / text post	~0.5 KB
Average size of a photo (compressed)	~200 KB – 2 MB
Average size of a short video (1 min)	~10 MB
Average HTTP request/response	~1–10 KB
Characters in a URL	~100 bytes

QPS Quick Math

Daily Active Users	Actions/User/Day	QPS (avg)	QPS (peak, ~3x avg)
1 million	10	~115	~350
10 million	10	~1,150	~3,500
100 million	10	~11,500	~35,000
1 billion	10	~115,000	~350,000

The formula: QPS = (DAU x actions per user) / 86,400. Peak QPS is typically 2x–5x the average. Always calculate peak, not just average — systems must handle bursts.

Storage Estimation Formula

Daily storage = DAU x actions/user x size per action
Monthly storage = Daily x 30
Yearly storage = Daily x 365
Plan for 3–5 years of growth + replication factor (usually 3x)

12. Design Pattern Quick Reference

Pattern	Problem It Solves	When NOT to Use
Singleton	Ensures one instance globally (config, connection pool)	When it hides dependencies or makes testing difficult
Factory Method	Decouples object creation from usage	When there is only one concrete type and it will not change
Observer	One-to-many notifications on state change	When the order of notification matters or chains get deep
Strategy	Swap algorithms at runtime without changing client code	When there is only one algorithm and no foreseeable variation
Decorator	Adds behavior to objects dynamically without subclassing	When the combination explosion of wrappers becomes unreadable
Adapter	Makes incompatible interfaces work together	When you can modify the original interface instead
Builder	Constructs complex objects step-by-step	For simple objects where a constructor with parameters suffices
Proxy	Controls access to an object (lazy load, access control, caching)	When the indirection adds latency with no real benefit
Circuit Breaker	Prevents cascading failures by stopping calls to failing services	When failures are transient and retries are cheap
CQRS	Separates read and write models for scalability	For simple CRUD apps where read/write patterns are identical

Distributed System Patterns Worth Knowing

Beyond OOP design patterns, these distributed system patterns come up frequently:

Pattern	Purpose
Saga	Manage distributed transactions across microservices
Event Sourcing	Store state changes as an immutable sequence of events
Sidecar	Attach utility processes alongside your main container
Bulkhead	Isolate failures to prevent one component from sinking all
Strangler Fig	Incrementally migrate from legacy to new system
Leader Election	Coordinate a single active node among replicas
Consistent Hashing	Distribute load evenly with minimal remapping on scaling
Outbox Pattern	Reliably publish events alongside database transactions

13. SOLID Principles — One-Liner

Principle	One-Liner	Code Smell It Prevents
S — Single Responsibility	A class should have only one reason to change.	God classes that touch everything
O — Open/Closed	Open for extension, closed for modification.	Modifying existing code every time a new type appears
L — Liskov Substitution	Subtypes must be usable wherever their parent type is expected.	Subclasses that break parent behavior or throw unexpected errors
I — Interface Segregation	No client should be forced to depend on methods it does not use.	Fat interfaces where implementors stub out half the methods
D — Dependency Inversion	Depend on abstractions, not concretions.	Tightly coupled modules that cannot be tested or swapped

Mnemonics and practical examples

S — Single Responsibility: Bad: A User class that handles authentication, database access, and email sending. Good: Separate UserAuth, UserRepository, and EmailService classes.O — Open/Closed: Bad: A giant if/else chain that grows every time you add a payment method. Good: A PaymentProcessor interface with StripeProcessor, PayPalProcessor implementations.L — Liskov Substitution: Bad: A Square that extends Rectangle but breaks when setWidth is called independently. Good: Use a common Shape interface instead of inheritance.I — Interface Segregation: Bad: A Worker interface with work(), eat(), sleep() — robots do not eat. Good: Split into Workable, Eatable, Sleepable interfaces.D — Dependency Inversion: Bad: OrderService creates new MySQLDatabase() directly. Good: OrderService accepts a Database interface via constructor injection.

14. Git Commands Engineers Actually Use

Beyond the Basics

Command	What It Does
`git log --oneline --graph --all`	Visualize the entire branch topology in your terminal
`git diff --staged`	See exactly what will be committed (staged changes only)
`git stash -u`	Stash all changes including untracked files
`git stash pop`	Re-apply the most recent stash and remove it from the stash list
`git cherry-pick <commit>`	Apply a single commit from another branch onto current branch
`git rebase -i HEAD~N`	Interactively squash, reorder, or edit the last N commits
`git bisect start / good / bad`	Binary search through commits to find the one that introduced a bug
`git reflog`	View the full history of HEAD — your safety net for “I lost my work”
`git reset --soft HEAD~1`	Undo last commit but keep changes staged
`git blame -L 10,20 file.py`	See who last modified lines 10–20 (great for understanding context)
`git log -S "functionName"`	Search commit history for when a string was added or removed
`git shortlog -sn --no-merges`	Leaderboard of contributors by commit count
`git clean -fd`	Remove all untracked files and directories (destructive)
`git worktree add ../feature-branch feature`	Check out a branch in a separate directory without switching
`git commit --fixup <commit>`	Mark a commit as a fixup for a previous commit (use with autosquash)

Aliases Worth Setting Up

git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.st status
git config --global alias.lg "log --oneline --graph --all --decorate"
git config --global alias.unstage "reset HEAD --"
git config --global alias.last "log -1 HEAD --stat"
git config --global alias.amend "commit --amend --no-edit"

Dangerous commands to use with caution: git reset --hard, git push --force, and git clean -fd are destructive and cannot be undone easily. Always prefer --force-with-lease over --force when pushing, as it prevents overwriting teammates’ work.

Quick-Find Index

Alphabetical topic index — jump to what you need

Topic	Section
API styles (REST, gRPC, etc.)	4
Authentication methods	6
Availability (“nines” table)	10
Back-of-envelope estimation	11
Caching strategies	3
Container orchestration (K8s)	8
Database selection	2
Deployment strategies	5
Design patterns	12
Git commands	14
HTTP status codes	9
Latency numbers	1
Message queues	7
SOLID principles	13

Interview Experiences

Think Like an Engineer

Interview Questions

Quick Reference Cheatsheet

1. Latency Numbers Every Engineer Should Know

2. Database Selection Matrix

3. Caching Strategy Decision Tree

4. API Style Comparison

5. Deployment Strategy Matrix

6. Authentication Method Decision Matrix

7. Message Queue Comparison

8. Container Orchestration Quick Reference

Core Kubernetes Objects

9. Common HTTP Status Codes for Engineers

Success (2xx)

Redirection (3xx)

Client Error (4xx)

Server Error (5xx)

10. The “Nines” Table — Availability Reference

11. Back-of-Envelope Estimation Cheat Sheet

Powers of 2 — Capacity Reference

Common Estimation Building Blocks

QPS Quick Math

Storage Estimation Formula

12. Design Pattern Quick Reference

13. SOLID Principles — One-Liner

14. Git Commands Engineers Actually Use

Beyond the Basics

Aliases Worth Setting Up

Quick-Find Index

Interview Experiences

Think Like an Engineer

Interview Questions

​1. Latency Numbers Every Engineer Should Know

​2. Database Selection Matrix

​3. Caching Strategy Decision Tree

​4. API Style Comparison

​5. Deployment Strategy Matrix

​6. Authentication Method Decision Matrix

​7. Message Queue Comparison

​8. Container Orchestration Quick Reference

​Core Kubernetes Objects

​9. Common HTTP Status Codes for Engineers

​Success (2xx)

​Redirection (3xx)

​Client Error (4xx)

​Server Error (5xx)

​10. The “Nines” Table — Availability Reference

​11. Back-of-Envelope Estimation Cheat Sheet

​Powers of 2 — Capacity Reference

​Common Estimation Building Blocks

​QPS Quick Math

​Storage Estimation Formula

​12. Design Pattern Quick Reference

​13. SOLID Principles — One-Liner

​14. Git Commands Engineers Actually Use

​Beyond the Basics

​Aliases Worth Setting Up

​Quick-Find Index

1. Latency Numbers Every Engineer Should Know

2. Database Selection Matrix

3. Caching Strategy Decision Tree

4. API Style Comparison

5. Deployment Strategy Matrix

6. Authentication Method Decision Matrix

7. Message Queue Comparison

8. Container Orchestration Quick Reference

Core Kubernetes Objects

9. Common HTTP Status Codes for Engineers

Success (2xx)

Redirection (3xx)

Client Error (4xx)

Server Error (5xx)

10. The “Nines” Table — Availability Reference

11. Back-of-Envelope Estimation Cheat Sheet

Powers of 2 — Capacity Reference

Common Estimation Building Blocks

QPS Quick Math

Storage Estimation Formula

12. Design Pattern Quick Reference

13. SOLID Principles — One-Liner

14. Git Commands Engineers Actually Use

Beyond the Basics

Aliases Worth Setting Up

Quick-Find Index