100 Essential System Design Concepts

A revision sheet covering 100 system design concepts, each with a concrete example, grouped from fundamentals through databases, distributed consistency, reliability and operations.

7-11 minutes(1491 words)complex

Quick Navigation

Difficulty: Intermediate
Estimated Time: 30-45 minutes
Prerequisites: Basic backend development, Familiarity with databases, Understanding of HTTP, Basic networking

A revision sheet: 100 system design concepts, each with a concrete example. Useful as interview preparation, as a vocabulary check before a design review, or as a map of what you have not yet had to learn.

Fundamentals (1-10)

  1. Latency — how long one request takes. 200 ms to start playing a video.
  2. Throughput — requests served per second. 10,000 concurrent streams.
  3. Vertical scaling — make the machine bigger. 16 GB to 128 GB of RAM.
  4. Horizontal scaling — add machines. 3 to 50 servers on Black Friday.
  5. Availability (SLA) — 99.99 percent means about 52 minutes of downtime per year.
  6. Fault tolerance — surviving the loss of a component. Three replicas, one dies, service continues.
  7. SPOF — single point of failure. One load balancer with no backup.
  8. Percentiles (p50/p95/p99) — the average lies. p99 at 3 s while p50 is 40 ms.
  9. Back-of-the-envelope estimation — size it before you design it. 1M users times 10 KB equals 10 GB/day.
  10. Amdahl's law — the sequential portion caps the benefit of parallelism.

Traffic and Distribution (11-20)

  1. L4 vs L7 load balancing — routing by IP and port versus by HTTP content. L7 sends /api and /img to different backends.
  2. Round-robin and least-connections — the distribution algorithms themselves.
  3. Sticky sessions — pinning a client to one server. An in-memory shopping cart, best avoided.
  4. Stateless services — no session state on the server. A JWT carries the identity.
  5. Reverse proxy — Nginx in front of the backends for TLS, compression and caching.
  6. DNS and GeoDNS — routing users to the nearest datacenter.
  7. Anycast — one IP address announced from several sites.
  8. CDN — static assets served at the edge. Cloudflare serves the image from Paris.
  9. Auto-scaling — add instances based on load. Five more pods when CPU exceeds 70 percent.
  10. Connection pooling — reuse database connections. PgBouncer, 20 connections serving 500 requests.

Caching (21-29)

  1. Cache-aside — the application reads the cache, falls back to the database, then fills the cache. The most common pattern.
  2. Write-through and write-back — write to the cache at the same time as the store, or later.
  3. LRU/LFU/TTL eviction — deciding what to drop when the cache is full.
  4. Cache stampede — a thousand requests hit the database the moment a key expires. Fix with a lock or randomised TTL.
  5. Invalidation — the genuinely hard problem. Purge the key at write time.
  6. Browser caching and HTTP headers — Cache-Control, ETag, 304 Not Modified.
  7. Local vs distributed cache — process memory (fast, inconsistent) versus Redis (shared).
  8. Hot key — one key overwhelms a single node. A celebrity profile, solved by replicating the key.
  9. Materialized view — precompute an expensive result. A leaderboard recalculated every 5 minutes.

Databases (30-45)

  1. SQL vs NoSQL — transactions versus flexible schema. PostgreSQL for payments, Cassandra for logs.
  2. B-tree index — lookup in O(log n). Login in 1 ms instead of 2 s.
  3. Composite indexes and column order — (user_id, date) serves WHERE user_id=... ORDER BY date.
  4. Primary-replica replication — writes to the primary, reads from the replicas.
  5. Synchronous vs asynchronous replication — durability versus latency.
  6. Sharding — split by key. A-M on shard 1, N-Z on shard 2.
  7. Range vs hash partitioning — sorted ranges versus uniform distribution.
  8. Consistent hashing — adding a node moves only 1/n of the keys.
  9. Cross-shard queries — expensive scatter-gather across every shard.
  10. ACID — atomicity, consistency, isolation, durability. A bank transfer.
  11. BASE — flexible, eventually consistent. A view counter.
  12. Isolation levels — read committed, repeatable read, serializable.
  13. Optimistic vs pessimistic locking — a version number versus SELECT FOR UPDATE.
  14. LSM-tree vs B-tree — write-optimised (Cassandra, RocksDB) versus read-optimised (MySQL).
  15. Write-ahead log — journal before applying, replayed after a crash.
  16. Columnar, time-series and graph stores — ClickHouse for analytics, InfluxDB for metrics, Neo4j for relationships.

Consistency and Distributed Systems (46-58)

  1. CAP theorem — under a partition, choose consistency or availability.
  2. PACELC — and without a partition, trade latency against consistency.
  3. Strong consistency — every read sees the latest write.
  4. Eventual consistency — replicas converge. An Instagram like appears after 2 seconds.
  5. Read-your-writes — the author sees their own comment immediately.
  6. Quorum, R + W greater than N — three replicas, write to two, read from two.
  7. Consensus (Raft, Paxos) — agreeing despite failures. etcd.
  8. Leader election — one node orders the writes.
  9. Split-brain — two leaders after a partition. Solved by majority quorum.
  10. Vector and Lamport clocks — ordering events without a global clock.
  11. CRDTs — structures that merge without conflict. Collaborative editing.
  12. Two-phase commit — blocking, and rarely used in practice.
  13. Saga — a distributed transaction with compensating actions. Cancel the flight if the hotel booking fails.

Communication (59-70)

  1. REST — resources, HTTP verbs, stateless.
  2. gRPC — binary over HTTP/2, fast between internal services.
  3. GraphQL — the client picks the fields; watch for N+1 queries.
  4. Message queues — Kafka or SQS decouple producer from consumer.
  5. Pub/sub — one event, many subscribers.
  6. At-least-once vs exactly-once — delivery guarantees, and why idempotency matters.
  7. Dead letter queue — failed messages set aside for inspection.
  8. Backpressure — slow the producer when the queue grows.
  9. WebSocket — persistent bidirectional connection. Chat.
  10. Server-sent events — a server-to-client stream. Live stock prices.
  11. Long polling — the simple fallback.
  12. Webhook — the provider calls your URL. Stripe notifies you of a payment.

Architecture (71-80)

  1. Monolith vs microservices — simplicity versus team autonomy.
  2. Domain-driven decomposition — services aligned to business domains.
  3. API gateway — authentication, routing and quotas at one point.
  4. Service mesh — Istio handles mTLS, retries and telemetry outside application code.
  5. Service discovery — Consul or DNS finds the live instances.
  6. Backend for frontend — one API shaped for mobile, another for web.
  7. Event sourcing — store the events, not the final state.
  8. CQRS — separate the write model from the read model.
  9. Sidecar — a companion container for cross-cutting concerns.
  10. Batch vs streaming — a nightly Spark job versus continuous Flink processing.

Reliability (81-90)

  1. Idempotency — replaying does not double the effect. Stripe's Idempotency-Key.
  2. Retry with exponential backoff and jitter — retry without causing a thundering herd.
  3. Circuit breaker — stop calling a failing service.
  4. Bulkhead — isolate pools so one failure does not contaminate the rest.
  5. Timeouts — never make a network call without one.
  6. Graceful degradation — serve a reduced version. Generic recommendations when the model is down.
  7. Health checks and heartbeats — Kubernetes restarts a pod after three failed probes.
  8. Rate limiting — token bucket, 100 requests per minute, otherwise HTTP 429.
  9. Chaos engineering — deliberately breaking things in production.
  10. Blue-green and canary — deploy to 1 percent of traffic before everyone.

Security and Operations (91-100)

  1. AuthN vs AuthZ — who you are versus what you may do. OAuth2 plus RBAC.
  2. JWT vs sessions — a self-contained signed token versus server-side state.
  3. TLS and mTLS — encryption, and mutual verification between services.
  4. Encryption at rest and secrets management — Vault, KMS, never a hardcoded secret.
  5. OWASP basics — SQL injection, XSS, CSRF.
  6. Observability — logs (what), metrics (how much), traces (where). Jaeger reveals 2.8 s spent in an unindexed query.
  7. SLI, SLO and error budget — measure, target, and arbitrate between speed and stability.
  8. Alert on symptoms — alert on user-visible latency, not on CPU.
  9. Backups with RPO and RTO — an untested backup does not exist.
  10. Feature flags — enable and disable without redeploying, and kill fast during an incident.

How to Use This List

Reading it end to end is the least useful thing you can do with it. Two better approaches:

  • Gap-finding. Go through once and mark every entry you could not explain to a colleague for two minutes. That list, not this one, is your study plan.
  • Design review checklist. Before shipping a design, walk the Reliability and Security sections and ask which of those ten items your design has an answer for. Most gaps in real systems are in items 81 to 90, not in the exotic distributed systems theory.

Depth matters more than coverage. Knowing that CAP exists is worth very little; being able to say which side your database picks under a network partition, and what your application does when that happens, is the actual skill.

Tags: #SystemDesign #DistributedSystems #Architecture #Scalability #Interview