# 100 System Design Concepts Explained Simply

**If you can't explain a system design concept in one minute, do you really understand it?**

One of the biggest mistakes engineers make is memorizing system design interview answers instead of understanding the underlying concepts.

Everyone knows words like *load balancing*, *sharding*, *caching*, and *event-driven architecture*. But far fewer people can explain **why** they exist, **when** to use them, and **what trade-offs** they introduce.

Great software architects don't collect buzzwords.

They build a mental model.

This guide explains **100 essential system design concepts** using simple language, making them easier to remember and apply in real-world systems.

* * *

## 1\. Scalability

The ability of a system to handle increasing traffic without significant performance degradation.

* * *

## 2\. Availability

How often a system remains operational and accessible.

* * *

## 3\. Reliability

The probability that a system performs correctly over time.

* * *

## 4\. Latency

The time it takes for a request to receive a response.

* * *

## 5\. Throughput

The number of requests a system can process per second.

* * *

## 6\. Bandwidth

The maximum amount of data that can be transferred over a network.

* * *

## 7\. Fault Tolerance

The ability to continue operating after failures occur.

* * *

## 8\. High Availability (HA)

Designing systems with minimal downtime through redundancy.

* * *

## 9\. Durability

Ensuring data survives crashes and hardware failures.

* * *

## 10\. Consistency

All users see the same data after updates.

* * *

## 11\. Eventual Consistency

Data becomes consistent after a short delay.

* * *

## 12\. Strong Consistency

Every read immediately reflects the latest write.

* * *

## 13\. CAP Theorem

Distributed systems can only fully achieve two of Consistency, Availability, and Partition Tolerance.

* * *

## 14\. Partition Tolerance

The system continues working despite network failures.

* * *

## 15\. ACID

Properties that guarantee reliable database transactions.

* * *

## 16\. BASE

A distributed alternative prioritising availability over strict consistency.

* * *

## 17\. Horizontal Scaling

Adding more servers.

* * *

## 18\. Vertical Scaling

Adding more CPU or memory to one server.

* * *

## 19\. Stateless Service

No user session stored locally.

* * *

## 20\. Stateful Service

Maintains session or user-specific data.

* * *

## 21\. Load Balancer

Distributes traffic across multiple servers.

* * *

## 22\. Reverse Proxy

Receives client requests before forwarding them internally.

* * *

## 23\. CDN

Caches static content closer to users.

* * *

## 24\. Cache

Stores frequently accessed data for faster retrieval.

* * *

## 25\. Cache Aside Pattern

Applications manage cache updates manually.

* * *

## 26\. Write Through Cache

Writes go to cache and database simultaneously.

* * *

## 27\. Write Back Cache

Writes reach the database asynchronously.

* * *

## 28\. Cache Invalidation

Removing outdated cached data.

* * *

## 29\. Cache Stampede

Many requests regenerate the same expired cache.

* * *

## 30\. Cache Penetration

Requests repeatedly query data that doesn't exist.

* * *

## 31\. Database Index

Speeds up searching like a book's index.

* * *

## 32\. Full Table Scan

Reading every database row.

* * *

## 33\. Query Optimisation

Improving SQL performance.

* * *

## 34\. Normalisation

Reducing duplicate data.

* * *

## 35\. Denormalisation

Adding redundancy for faster reads.

* * *

## 36\. Replication

Copying data across servers.

* * *

## 37\. Master-Replica

One server writes, replicas read.

* * *

## 38\. Sharding

Splitting data across multiple databases.

* * *

## 39\. Partitioning

Breaking large tables into smaller pieces.

* * *

## 40\. Data Lake

Stores raw structured and unstructured data.

* * *

## 41\. Data Warehouse

Optimised for analytics.

* * *

## 42\. OLTP

Online transaction processing.

* * *

## 43\. OLAP

Online analytical processing.

* * *

## 44\. Message Queue

Buffers asynchronous communication.

* * *

## 45\. Event Streaming

Continuously processing event data.

* * *

## 46\. Publish-Subscribe

Publishers don't know subscribers.

* * *

## 47\. Event Sourcing

Store events instead of current state.

* * *

## 48\. CQRS

Separate read and write models.

* * *

## 49\. Saga Pattern

Coordinates distributed transactions.

* * *

## 50\. Two-Phase Commit

Ensures distributed transaction consistency.

* * *

## 51\. API Gateway

Single entry point for APIs.

* * *

## 52\. Service Discovery

Services automatically locate one another.

* * *

## 53\. Microservices

Independent deployable services.

* * *

## 54\. Monolith

Entire application deployed together.

* * *

## 55\. Modular Monolith

Single deployment with clear internal boundaries.

* * *

## 56\. Service Mesh

Handles communication between services.

* * *

## 57\. Sidecar Pattern

Adds infrastructure features beside applications.

* * *

## 58\. Circuit Breaker

Stops repeated failures from cascading.

* * *

## 59\. Retry Pattern

Automatically retries failed requests.

* * *

## 60\. Timeout

Limits how long operations wait.

* * *

## 61\. Bulkhead Pattern

Isolates failures into separate resources.

* * *

## 62\. Rate Limiting

Restricts request frequency.

* * *

## 63\. Throttling

Slows traffic when limits are exceeded.

* * *

## 64\. Backpressure

Signals producers to slow down.

* * *

## 65\. Idempotency

Repeated requests produce the same result.

* * *

## 66\. Sticky Session

User consistently reaches the same server.

* * *

## 67\. Session Store

Centralised user session storage.

* * *

## 68\. Authentication

Verifying identity.

* * *

## 69\. Authorisation

Checking permissions.

* * *

## 70\. OAuth 2.0

Delegated access protocol.

* * *

## 71\. JWT

Self-contained authentication token.

* * *

## 72\. SSO

One login for multiple systems.

* * *

## 73\. Encryption

Protecting data using cryptography.

* * *

## 74\. TLS

Secures communication over networks.

* * *

## 75\. Hashing

One-way transformation for integrity.

* * *

## 76\. Observability

Understanding internal system behaviour.

* * *

## 77\. Logging

Recording application events.

* * *

## 78\. Monitoring

Tracking system health.

* * *

## 79\. Metrics

Numerical performance measurements.

* * *

## 80\. Tracing

Following requests across services.

* * *

## 81\. Alerting

Notifying engineers about issues.

* * *

## 82\. Blue-Green Deployment

Switching traffic between two environments.

* * *

## 83\. Canary Deployment

Releasing changes gradually.

* * *

## 84\. Rolling Deployment

Updating servers incrementally.

* * *

## 85\. Feature Flags

Enable features without redeployment.

* * *

## 86\. CI/CD

Automated build, testing and deployment.

* * *

## 87\. Container

Packages applications consistently.

* * *

## 88\. Docker

Popular container platform.

* * *

## 89\. Kubernetes

Container orchestration platform.

* * *

## 90\. Infrastructure as Code

Infrastructure managed through code.

* * *

## 91\. Immutable Infrastructure

Servers are replaced instead of modified.

* * *

## 92\. Autoscaling

Automatically adjusts system capacity.

* * *

## 93\. Disaster Recovery

Recovering after catastrophic failures.

* * *

## 94\. RPO

Maximum acceptable data loss.

* * *

## 95\. RTO

Maximum acceptable downtime.

* * *

## 96\. Edge Computing

Processing data closer to users.

* * *

## 97\. Distributed Lock

Coordinates shared resource access.

* * *

## 98\. Leader Election

Selecting one node to coordinate tasks.

* * *

## 99\. Consensus Algorithm

Multiple nodes agree on a shared state.

* * *

## 100\. System Design

The art of building scalable, reliable, maintainable, and efficient software systems that solve real business problems.

* * *

## Final Thoughts

System design isn't about memorising architecture diagrams.

It's about understanding **trade-offs**.

Every architecture decision improves one aspect while making another more complex.

The best engineers don't ask:

> **"Which technology should I use?"**

They ask:

> **"Which trade-off am I willing to accept?"**

Master these 100 concepts, and you'll have a solid foundation for:

*   System design interviews
    
*   Software architecture
    
*   Backend engineering
    
*   Cloud-native development
    
*   Distributed systems
    
*   Technical leadership
    

Because great architects don't memorise patterns.

**They understand why the patterns exist.**

* * *

**What concept do you think every software engineer should truly understand—but is often misunderstood?**

Let's discuss in the comments.