ImageFirm / Systems Lab
Fact-checked • refined • 2026 edition

System Design, without the shortcuts.

A technically corrected, modernized version of the popular “system design cheatsheet” format — useful for interviews, but rewritten for real architecture decisions.

Overall accuracy
82% directionally correct

Strong as a beginner revision aid. Weaker as an academic or production architecture reference.

8.5/10Beginner revision
8/10Interview quick ref
7/10Technical precision
6.5/10Academic reference
01 · Critical correction

CAP theorem is not “pick any two.”

Misleading

Common shortcut

“Consistency, availability, partition tolerance — you can only have two out of three.”

Better formulation

When a network partition occurs, a distributed system cannot simultaneously guarantee both strong consistency and availability.

The key nuance: in a truly distributed system, network partitions are a condition you must expect. During a partition, the operational trade-off becomes consistency versus availability.

Consistency

Clients observe a state consistent with the chosen model; under strong consistency this means operations appear in a single coherent order.

Availability

Every request to a non-failing node receives a response, even while parts of the distributed system cannot communicate.

02 · Scaling

Vertical and horizontal scaling are correctly identified — but incomplete.

Mostly correct

Vertical scaling · Scale up

Add CPU, memory, storage or faster hardware to a single machine. Simple operationally, but bounded by hardware limits and fault-domain concentration.

Horizontal scaling · Scale out

Add nodes or instances. This can improve capacity and resilience, but introduces distributed-state, coordination and consistency concerns.

Replication Sharding Service discovery Distributed coordination Failover Load balancing
03 · Data storage

SQL vs NoSQL should be a workload decision, not a slogan.

Oversimplified

Relational / SQL

Strong fit for relational data, expressive queries, joins, constraints and mature transaction semantics. Modern relational systems can also scale horizontally and store JSON/document data.

NoSQL

An umbrella category covering document, key-value, wide-column and graph databases. Often chosen for access-pattern fit, distribution model, scale characteristics or flexible schemas.

Selection lens: data model → query patterns → consistency requirements → transaction semantics → latency targets → scalability → operational complexity → cost.
04 · Messaging infrastructure

Kafka and RabbitMQ solve overlapping — not identical — problems.

Needs nuance

Message brokers

Systems such as RabbitMQ focus on routing and delivering messages between producers and consumers with queue- and broker-oriented semantics.

Event streaming platforms

Systems such as Kafka center on durable ordered event logs, partitions, consumer offsets, replay and high-throughput event streams.

05 · Architecture patterns

CQRS and event-driven architecture are related — but not synonyms.

Conceptually sound

CQRS

Separates command/write responsibilities from query/read responsibilities. Separation can be logical or physical; it does not inherently require separate databases or microservices.

Event-driven architecture

Components communicate through events. Real production design must address delivery semantics, retries, ordering, duplicate handling, schema evolution and backpressure.

Important: CQRS ≠ Event Sourcing. They are frequently combined, but neither requires the other.
06 · Important concepts

The cheat sheet’s definitions are useful — with one major wording fix.

Good foundation
LatencyTime required for an operation or request to complete.
ThroughputAmount of work handled per unit time.
AvailabilityDegree to which a system remains operational and accessible.
ReliabilityAbility to perform correctly over time under expected conditions.
Fault toleranceAbility to continue operating despite component failures.
ConsistencyRules governing how state and updates become visible across the system.
IdempotencyRepeating the same operation has the same intended effect on system state as doing it once.
DurabilityCommitted data survives the failures covered by the storage system’s guarantees.
Why idempotency matters: identical HTTP responses are not required. What matters is that repeated execution does not cause unintended repeated state changes.
07 · Missing from the original

A real system-design guide needs more than vocabulary.

Important omissions
Replication strategies Sharding / partitioning Indexes Read replicas Consistency models Quorum reads / writes Leader / follower Distributed transactions Eventual consistency Rate limiting API versioning Authentication Authorization Circuit breakers Retry + backoff Observability Disaster recovery RPO / RTO Multi-region design Stateful vs stateless Backpressure Security architecture
08 · ImageFirm framework

A stronger way to reason about architecture.

Production-ready thinking
Requirements — define users, use cases, functional scope and constraints.
Workload — estimate traffic, read/write mix, payloads, growth and concurrency.
SLOs — specify latency, availability, durability and recovery objectives.
Capacity — derive bandwidth, storage, compute and hot-path requirements.
Data model — design entities, relationships, access patterns and lifecycle.
Architecture — choose boundaries, services, queues, caches and storage.
Consistency — make explicit where strong, causal or eventual consistency is acceptable.
Scaling — define replication, partitioning, autoscaling and routing strategy.
Failure modes — model node, network, dependency, region and operator failures.
Security — identity, authorization, data protection, isolation and abuse resistance.
Observability — metrics, traces, logs, alerts and operational diagnostics.
Cost & trade-offs — explain what is gained, what is sacrificed and why.
Final verdict

Good interview memory aid. Not yet a rigorous architecture framework.

8.5/10Beginner revision
8/10Interview quick reference
7/10Technical precision
6.5/10Academic / professional reference

The original material demonstrates solid familiarity with mainstream system-design terminology. Its largest weakness is not incorrect vocabulary, but compression: important distributed-systems trade-offs are reduced to slogans. The refined version above preserves the accessibility while restoring the technical distinctions that matter in real architecture work.