Sefism System Design Cheat Sheet

What this cheat sheet is

The System design cheat sheet is the quick-revision companion to the System design roadmap on Sefism. It puts the core building blocks and trade-offs on a few pages for engineers who want to refresh them quickly: ten chapters, 79 concepts and an A to Z glossary of 144 further terms.

Unlike the language-based sheets, it has no editions; everyone reads the same content. Most of it is explanation rather than code, because system design is mostly about choices. Each concept says what it is and why it is used, and many add the classic mistake people make with it. A handful of concepts include a short snippet where code genuinely helps, such as cache-aside, a query plan, idempotency keys, an estimation worked in numbers, and a design walkthrough.

Chapter by chapter

1. Core concepts: scale, latency and availability (7 concepts)

Vertical versus horizontal scaling, stateless services, latency versus throughput, percentile latency (p50, p95, p99), availability and the nines, redundancy and single points of failure, and SLI, SLO and SLA. The vocabulary every later chapter uses.

2. Load balancing, proxies, CDNs and caching (8 concepts)

Load balancers at layer 4 and layer 7, balancing algorithms, reverse proxies and API gateways, CDNs, cache-aside, cache invalidation and TTL, eviction policies, and the cache stampede.

3. Databases: models, indexes and transactions (8 concepts)

SQL versus NoSQL, the NoSQL families, normalisation and denormalisation, indexes, query plans, ACID transactions, isolation levels and the write-ahead log: how data is modelled, found and changed safely on one machine.

4. Replication, partitioning and sharding (7 concepts)

Leader-follower replication, synchronous versus asynchronous replication, replication lag and read-your-writes, multi-leader and leaderless replication, partitioning, sharding and shard keys, and rebalancing and resharding.

5. Networking and APIs (8 concepts)

DNS, TCP versus UDP, HTTP/1.1, HTTP/2 and HTTP/3, TLS, REST, gRPC, GraphQL, and WebSockets, SSE and long polling.

6. Messaging, queues and streams (8 concepts)

Synchronous versus asynchronous communication, message queues, publish-subscribe, event streams with Kafka, delivery semantics, idempotency and idempotency keys, dead letter queues and the transactional outbox.

7. Distributed systems fundamentals (9 concepts)

The CAP theorem, PACELC, consistency models, quorum reads and writes, leader election and consensus with Raft, consistent hashing, heartbeats and gossip, Merkle trees and Bloom filters.

8. Architecture and resilience patterns (8 concepts)

Monolith versus microservices, backend for frontend and sidecars, timeouts, retries and backoff with jitter, circuit breakers, rate limiting, graceful degradation and load shedding, sagas, and event sourcing and CQRS.

9. Observability and safe releases (8 concepts)

Metrics and the golden signals, structured logging, distributed tracing and correlation IDs, health checks, alerting on SLOs and error budgets, blue-green and canary deployments, feature flags and chaos engineering.

10. Estimation, building blocks and a design approach (8 concepts)

Back-of-the-envelope estimation, latency numbers to know, object storage, search indexes, unique ID generation, requirements and scope, API and data model first, and a full design walkthrough. This is the chapter to reread before working through a design end to end.

Eight rules of thumb

The sheet closes with eight rules worth keeping in your head:

• Every choice has a cost on both sides: say what you gain, what you give up and why that fits the requirements.
• Read-heavy means cache and replicas, write-heavy means queues and sharding, large files mean object storage and a CDN.
• Start with one database and a modular monolith, and split only when a measured bottleneck forces it.
• Put a timeout on every network call and make every retried operation idempotent.
• Design for the p99, not the average.
• For each box on a diagram, ask what happens when it is slow, down or overloaded.
• Do the numbers before the diagram.
• Choose consistency per feature: payments need it strongly, like counts and feeds rarely do.

How to use it with the roadmap

The roadmap's seven stages map roughly onto the ten chapters: stage 1 to chapters 1 and 2, stage 2 to chapters 3 and 4, stage 3 to chapters 5 and 6, stage 4 to chapter 7, stage 5 to chapter 8, stage 6 to chapter 9, and stage 7 to chapter 10.

• After each stage: read the matching chapters and explain each concept aloud, with its trade-off. If you can only name it, go back.
• Before a design discussion at work: skim the chapters for the parts you are about to change, and run through the rules of thumb.
• While practising full designs: keep chapter 10 open for the order of work, and use the glossary to check terms you reach for.
• When reading an engineering blog post: look up each component it mentions and note which trade-off the team chose.

How it works on Sefism

The public page at /cheatsheets/system-design/ shows every chapter's title and introduction, with the first chapters open to read in full. Everything on Sefism is free to learn from. Keeping a cheat sheet uses credits; new members get starting credits, and if you are learning seriously and run out you can ask for more. Keeping the sheet opens every chapter in the member area.

Following the System design roadmap also unlocks this sheet, and your first roadmap is free. Topics in the roadmap link to the concepts that cover them here.

Related on Sefism

• The System design roadmap this sheet accompanies.
• Designing Data-Intensive Applications for chapters 3, 4 and 7.
• Azure cloud design patterns for chapter 8.
• OpenTelemetry documentation for chapter 9.
• How do I learn system design as a student or junior developer?

Frequently asked questions

Is a cheat sheet enough to learn system design? No. It is for revision. The roadmap is where you learn each idea and practise designs; the sheet helps you keep the vocabulary and trade-offs fresh.

Does it cover specific products like Kafka or Redis? Where they are the usual example: event streams are explained with Kafka, and the caching chapter links to the Redis documentation. The focus stays on the concepts, which carry across products.

Why are there so few code snippets? Because most system design decisions are trade-offs, not code. The five snippets are where a few lines make an idea clearer than prose.