AlgoInsight

System Design

30 System Design Concepts, One Mega-Guide

The complete map of the system design territory in one place. Thirty concepts, each explained plainly, grouped so you can see how they fit together - your starting point and your revision checklist.

By Admin2026-06-1816 min readsystem-designinterview-prepdistributed-systemsconceptsreferencescalability

System design can feel like an ocean of terminology - sharding, quorums, consistent hashing, circuit breakers, back-pressure - thrown at you with no map of how it all connects. This guide is the map. It collects thirty core concepts that show up again and again in system design interviews and real architecture, explains each one plainly, and groups them so you can see the shape of the whole field at once.

Treat this as two things: a starting point if you're new (read top to bottom and you'll have the vocabulary), and a revision checklist if you're experienced (skim the headers the night before an interview and you'll know which areas feel shaky). Each concept here is a doorway - many have full deep-dive articles of their own, linked where they exist.

graph TD
    SD[System Design] --> A[Scalability &<br/>Performance]
    SD --> B[Databases &<br/>Storage]
    SD --> C[Communication &<br/>APIs]
    SD --> D[Reliability &<br/>Resilience]
    SD --> E[Data Distribution<br/>& Processing]

This diagram organizes system design into five families of concepts: scalability and performance; databases and storage; communication and APIs; reliability and resilience; and data distribution and processing. The thirty concepts that follow are grouped under these five families.

Part 1 - Scalability & Performance

1. Vertical vs Horizontal Scaling. Two ways to handle more load. Vertical scaling means a bigger machine (more CPU, more memory) - simple, but it has a ceiling and remains a single point of failure. Horizontal scaling means more machines working together - scales almost without limit, but introduces coordination, load balancing, and data distribution. Most large systems scale up until they can't, then scale out.

2. Load Balancing. Distributing incoming requests across multiple servers so no single one is overwhelmed. A load balancer sits in front of your servers and routes each request, using strategies like round-robin or least-connections. It's foundational to horizontal scaling and also improves availability - if one server dies, traffic routes to the others.

3. Caching. Storing the result of expensive work so future requests skip it. A cache hit returns data in microseconds instead of querying a database. Caching happens at many layers - browser, CDN, application, database. The hard part is invalidation: a cache holds a copy that can go stale, and deciding when to refresh it is famously one of the hardest problems in computing.

4. CDN (Content Delivery Network). A globally distributed network of servers that cache content near users. A request from Tokyo is served from a nearby edge server rather than a distant origin, defeating the latency of physical distance. Essential for static assets like images and video, and increasingly for cacheable API responses.

5. Latency vs Throughput. Latency is how long one request takes; throughput is how many requests per second the system handles. They're distinct - a system can have high throughput and high latency simultaneously. Knowing which one a design optimizes for (and at what cost to the other) is a core system design instinct.

6. Rate Limiting. Capping how many requests a client can make in a time window, protecting your system from overload, abuse, and runaway costs. Algorithms like the token bucket allow controlled bursts while enforcing a steady average. At scale, the counter must be shared across servers (usually in Redis) with atomic operations to avoid races.

Part 2 - Databases & Storage

7. SQL vs NoSQL. Relational (SQL) databases offer strong consistency, joins, and transactions with a fixed schema. NoSQL databases trade some of those guarantees for horizontal scale and schema flexibility. The choice is never which is "better" - it's which guarantee you can afford to relax for the scale and access patterns you have.

8. Database Indexing. A data structure that lets the database find rows without scanning the whole table - the difference between a query taking seconds and milliseconds. The cost is slightly slower writes (the index must be maintained) and extra storage, so you index the columns you actually query.

9. Sharding (Partitioning). Splitting a database that's too big for one machine across many machines, each holding a slice ("shard") of the data. This enables horizontal scaling of data, but adds complexity: you need a strategy for which shard holds what, and queries spanning shards become harder.

10. Replication. Keeping copies of your data on multiple machines for both performance (spread reads across replicas) and reliability (if one copy dies, others survive). The central challenge is keeping replicas in sync - which immediately raises consistency questions.

11. ACID Transactions. A set of guarantees - Atomicity, Consistency, Isolation, Durability - that make database operations reliable. Atomicity means all-or-nothing; durability means committed data survives crashes. ACID is why you can trust a bank transfer to either fully happen or fully not. Distributed systems often relax these guarantees to gain scale.

12. Denormalization. Deliberately duplicating data to avoid expensive joins, trading storage and write complexity for much faster reads. The flip side of normalization (eliminating duplication for correctness). Which you choose depends on whether the workload is read-heavy or write-heavy.

13. Database Durability. The guarantee that once a write is confirmed, it survives even a crash. Achieved through techniques like write-ahead logging, where changes are recorded to durable storage before being applied, so the system can recover after a failure.

Part 3 - Communication & APIs

14. API (Application Programming Interface). The contract that lets software talk to other software - defining what requests you can make and what responses you'll get. Web APIs (over HTTP) are the connective tissue of modern systems. A clean API design is step one of almost every system you'll build.

15. REST vs GraphQL. Two API styles. REST exposes resources at multiple endpoints using HTTP verbs; it's simple and cacheable but can over- or under-fetch data. GraphQL exposes a single endpoint where clients query exactly the data they need; it's flexible but harder to cache. Each fits different needs.

16. Message Queues. A buffer that holds messages between a producer and a consumer, decoupling them. The producer drops a message and moves on; the consumer processes it when ready. Queues absorb traffic spikes, enable asynchronous processing, and let parts of a system fail and recover independently.

17. Pub-Sub (Publish-Subscribe). A messaging pattern where publishers send messages to a topic and any number of subscribers receive them, without publishers and subscribers knowing about each other. Ideal for broadcasting events to many interested parties - like notifying several services that an order was placed.

18. WebSockets. A protocol providing a persistent, two-way connection between client and server, so the server can push data to the client instantly without the client asking. Essential for real-time features - chat, live updates, multiplayer - where polling would be too slow or wasteful.

19. API Gateway. A single entry point that sits in front of your services, handling cross-cutting concerns - authentication, rate limiting, routing, request aggregation - so individual services don't each reimplement them. Common in microservices architectures.

20. Idempotency. The property that doing an operation multiple times has the same effect as doing it once. Critical in distributed systems because networks force retries - and without idempotency, a retried "charge the card" request charges twice. Implemented with idempotency keys that let a server recognize and safely ignore duplicates.

Part 4 - Reliability & Resilience

21. Redundancy. Having backup copies of components so that if one fails, another takes over. The foundation of high availability - no single component should be able to take down the whole system.

22. Single Point of Failure (SPOF). Any component whose failure alone brings down the entire system - a lone database, a lone load balancer, a hidden shared dependency. Finding and eliminating SPOFs through redundancy is among the highest-return reliability work you can do.

23. Failover. The process of automatically switching to a backup component when the primary fails. Good failover is fast and seamless; the catch is that an untested failover path is itself a hidden point of failure.

24. Heartbeats. Periodic "I'm alive" signals that let a system detect when a node has failed. If heartbeats stop arriving within a timeout, the node is presumed dead and the system reacts. The hard part is tuning the timeout - too short and healthy-but-slow nodes get falsely declared dead; too long and real failures take ages to detect.

25. Circuit Breakers. A pattern that stops calling a dependency that's clearly failing, "tripping" after too many failures to fail fast instead of wasting time on a dead service. After a cooldown, it cautiously tests whether the dependency has recovered. Prevents one failing component from dragging down everything that depends on it.

26. Consistency Models (Strong vs Eventual). Strong consistency means every read sees the latest write immediately; eventual consistency means replicas may briefly disagree before converging. Strong is required where wrong data causes harm (payments); eventual is fine where staleness is cheap (likes, feeds). Real systems choose per piece of data.

27. CAP Theorem. In a distributed system, when a network partition happens, you must choose between Consistency and Availability - you can't have both. Since partitions are inevitable, the real question CAP poses is: when the network splits, do you refuse stale answers (stay consistent) or keep answering (stay available)?

Part 5 - Data Distribution & Processing

28. Consistent Hashing. A technique for distributing data across servers such that adding or removing a server only moves a small fraction of keys, instead of remapping nearly everything. By placing servers and keys on a "ring" and walking clockwise, it makes scaling graceful - the backbone of distributed caches and databases.

29. Bloom Filters. A space-efficient probabilistic data structure that answers "is this item definitely not in the set, or possibly in it?" It can have false positives but never false negatives, using a tiny fraction of the memory a full set would need. Used to avoid expensive lookups - e.g., checking a cache or disk only when the item might actually be there.

30. Batch vs Stream Processing. Two ways to process data. Batch processing handles large chunks of data at scheduled intervals - efficient for big, non-urgent jobs. Stream processing handles data continuously as it arrives - essential for real-time needs like live analytics or fraud detection. Many systems use both.

How these concepts combine: a worked example

The real test of understanding isn't reciting these thirty concepts individually - it's seeing how they interlock when you design something. Let's watch a dozen of them come together in a single design: a URL shortener (think bit.ly), one of the most common interview prompts.

A user submits a long URL and gets back a short code; later, anyone visiting that short code is redirected to the original. Simple on the surface - but watch the concepts stack up.

First, scale and the read/write ratio. Short links are written once but read many thousands of times - this system is overwhelmingly read-heavy, which immediately tells us to optimize hard for reads. That single observation (concept 5) shapes everything downstream.

To generate the short codes, we need unique IDs that don't collide across multiple servers - we can't use a single database counter without it becoming a bottleneck, so we reach for a distributed ID scheme. Storing the mappings, we hit SQL vs NoSQL (concept 7): the access pattern is a simple key-value lookup (short code → long URL), so a NoSQL key-value store fits naturally and scales horizontally through sharding (concept 9).

Because reads dominate, we put a cache (concept 3) in front of the database - popular links live in memory and return in microseconds. We add a CDN (concept 4) so the redirect happens close to the user geographically. To keep the database from being a single point of failure, we use replication (concept 10) with read replicas spreading the load, accepting eventual consistency (concept 26) since a brand-new link being readable a half-second late is harmless.

We add a load balancer (concept 2) to spread traffic across application servers, rate limiting (concept 6) to stop abuse of the link-creation endpoint, and heartbeats (concept 24) plus failover (concept 23) so a dead server is detected and bypassed. We define a clean API (concept 14) - POST /shorten and GET /{code} - as the contract.

Count them: in one modest system, we naturally touched more than a dozen of the thirty concepts, and each choice created a trade-off that connected to another. The read-heavy ratio drove the caching, which raised consistency questions, which we resolved by accepting eventual consistency because the use case allowed it. That chain of reasoning - not the individual definitions - is what system design actually is.

Tip: A powerful way to study with this guide: take any common system (a chat app, a news feed, a ride-sharing service) and walk the five families, asking which concepts apply and what trade-offs each introduces. You'll quickly find the same thirty concepts recombine in different proportions for every system - which is exactly why mastering them generalizes so well.

How to use this map

These thirty concepts aren't isolated facts - they interlock. Caching reduces latency but introduces consistency problems. Replication improves reliability but raises the CAP question. Sharding enables scale but complicates transactions. A reliability mechanism like heartbeats only matters because failover depends on it; idempotency only matters because retries are inevitable. The skill of system design is seeing those connections: knowing that a choice in one area creates a trade-off in another, and being able to navigate them deliberately rather than being surprised by them.

Interview: Don't try to mention all thirty in one interview - that reads as a memorized list. Instead, use this as a coverage check. After designing a system, mentally walk the five families: Have I addressed scaling? Storage? Communication? Reliability? Data distribution? The gaps are where the interviewer's follow-up questions will land, so spotting them yourself first is exactly the move that earns a strong signal.

If any concept here felt shaky, that's a signal to go deeper on it - most of these have full dedicated articles, and all of them are taught with worked examples and trade-offs in System Design Fundamentals. This guide is the map; the course is the territory. The goal isn't to memorize thirty definitions - it's to reach the point where, handed any system to design, you can walk the five families instinctively, recognize which concepts the problem calls for, and reason out loud about the trade-offs each one introduces. That fluency is what interviewers are really testing, and it's what these thirty concepts, practiced together, are designed to build.

Go deeper

More articles