System Design Visual Guide
Ace your system design interviews and architect real systems with confidence. This visual guide breaks down 25+ common system architectures — URL shortener, real-time chat, rate limiter, distributed cache, notification service, and more — into clear component diagrams with data flow annotations, capacity estimates, database schema choices, and trade-off discussions. Each design follows a consistent template: requirements → estimates → API → data model → high-level design → deep dives → bottlenecks.
What's Included
- Core Building Blocks — Load balancers, caches, queues, CDNs, databases, search indexes
- URL Shortener — Hashing strategies, base62 encoding, analytics, redirect flow
- Real-Time Chat — WebSocket management, message storage, presence, delivery guarantees
- Rate Limiter — Token bucket, sliding window, distributed rate limiting with Redis
- Distributed Cache — Consistent hashing, eviction policies, cache-aside vs write-through
- Notification Service — Multi-channel (push, email, SMS), priority queues, retry logic
- News Feed / Timeline — Fan-out on write vs read, ranking, pagination
- File Storage (like S3) — Chunked uploads, metadata service, replication, CDN integration
- Search Autocomplete — Trie data structures, prefix matching, ranking by popularity
- Design Template — Reusable framework for approaching any system design problem
- Capacity Estimation Cheatsheet — Back-of-envelope math for storage, bandwidth, QPS
Preview / Sample Content
System Design Template — The Framework
1. REQUIREMENTS (5 min)
Functional: What does the system DO?
Non-functional: Scale, latency, availability, consistency
Out of scope: What are we NOT building?
2. CAPACITY ESTIMATES (5 min)
Users: DAU, peak concurrent
Storage: Per-record size × records/day × retention
Bandwidth: Requests/sec × avg payload size
Cache: 80/20 rule — cache 20% of daily data
3. API DESIGN (5 min)
Define 3-5 core endpoints
Input parameters, return types, error cases
4. DATA MODEL (5 min)
Tables/collections, key fields, indexes
SQL vs NoSQL decision with justification
5. HIGH-LEVEL DESIGN (10 min)
Component diagram with data flow arrows
Client → LB → API → Cache/DB → Queue → Workers
6. DEEP DIVES (15 min)
Pick 2-3 areas to go deeper
Scaling, consistency, failure handling
7. BOTTLENECKS & TRADE-OFFS (5 min)
Single points of failure
CAP theorem trade-offs
Cost optimization opportunities
Rate Limiter — Component Design
┌──────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────┐
│ Client │────▶│ Load Balancer│────▶│ Rate Limiter │────▶│ API │
└──────────┘ └──────────────┘ │ Middleware │ │ Server │
└──────┬───────┘ └──────────┘
│
┌──────▼───────┐
│ Redis │
│ (counters + │
│ timestamps) │
└──────────────┘
ALGORITHMS:
┌─────────────────────────────────────────────────────────────────────┐
│ Token Bucket │
│ - Tokens added at fixed rate (e.g., 10/sec) │
│ - Each request consumes 1 token │
│ - Bucket has max capacity (burst limit) │
│ - Pros: allows bursts, memory efficient │
│ - Cons: tuning bucket size vs refill rate │
├─────────────────────────────────────────────────────────────────────┤
│ Sliding Window Log │
│ - Store timestamp of each request │
│ - Count requests in current window │
│ - Pros: most accurate │
│ - Cons: high memory (stores every timestamp) │
├─────────────────────────────────────────────────────────────────────┤
│ Sliding Window Counter │
│ - Hybrid: fixed window + weighted overlap │
│ - Pros: memory efficient + reasonably accurate │
│ - Cons: approximate (not exact) │
│ - RECOMMENDED for most production use cases │
└─────────────────────────────────────────────────────────────────────┘
Capacity Estimation — Quick Math Reference
STORAGE ESTIMATES:
1 char = 1 byte (ASCII) / 2-4 bytes (UTF-8)
1 UUID = 36 bytes (string) / 16 bytes (binary)
1 timestamp = 8 bytes
1 URL = ~100 bytes average
1 tweet = ~300 bytes (text + metadata)
1 photo = ~200 KB (compressed)
1 video minute = ~50 MB (720p) / ~150 MB (1080p)
SCALE REFERENCE:
1 million = 10^6 (1 MB if 1 byte each)
1 billion = 10^9 (1 GB if 1 byte each)
1 trillion = 10^12 (1 TB if 1 byte each)
TIME CONVERSIONS:
1 day = 86,400 seconds ≈ 10^5
1 month = 2.6M seconds ≈ 2.5 × 10^6
1 year = 31.5M seconds ≈ 3 × 10^7
QPS ESTIMATION:
DAU × avg_actions_per_day / 86,400 = average QPS
Peak QPS ≈ 2-5× average QPS
CACHE SIZING (80/20 rule):
Daily requests × avg_response_size × 0.2 = cache size
Quick Reference Table
| System | Key Components | Primary DB | Cache Strategy | Scale Challenge |
|---|---|---|---|---|
| URL Shortener | Hash generator, redirect service | SQL (Postgres) | Cache hot URLs | Read-heavy (100:1) |
| Chat App | WebSocket gateway, message store | Cassandra/ScyllaDB | Recent messages | Connection management |
| Rate Limiter | Counter middleware | Redis | N/A (Redis IS cache) | Distributed counting |
| News Feed | Fan-out service, ranking | SQL + Redis | Timeline cache | Fan-out to millions |
| Notification | Priority queues, workers | SQL + queue | Template cache | Multi-channel delivery |
| Search Autocomplete | Trie service, ranking | Redis/Trie | Prefix cache | Real-time updates |
| File Storage | Chunk manager, metadata | SQL + blob store | CDN edge cache | Large file uploads |
| Distributed Cache | Hash ring, eviction | In-memory | Self (it IS cache) | Consistency, rebalancing |
Comparison: Database Selection Guide
| Requirement | Best Choice | Examples | Why |
|---|---|---|---|
| ACID transactions | Relational SQL | PostgreSQL, MySQL | Strong consistency guarantees |
| High write throughput | Wide-column store | Cassandra, ScyllaDB | Partitioned writes, no locks |
| Flexible schema | Document store | MongoDB, DynamoDB | Schema-per-document |
| Social graph / relations | Graph database | Neo4j, Neptune | Traversal queries O(1) per hop |
| Full-text search | Search engine | Elasticsearch, Meilisearch | Inverted index, BM25 ranking |
| Real-time counters | In-memory store | Redis, Memcached | Sub-millisecond reads/writes |
| Time-series data | Time-series DB | InfluxDB, TimescaleDB | Time-based partitioning + rollup |
| Event streaming | Log-based store | Kafka, Pulsar | Append-only, replay capability |
Usage Tips
- Memorize the design template — following the 7-step framework keeps you structured during interviews and real architecture sessions.
- Use the capacity estimation sheet during back-of-envelope calculations — the pre-computed reference numbers save time.
- Study 2-3 designs deeply rather than all 25 superficially — the patterns (fan-out, sharding, caching) repeat across systems.
- Focus on trade-offs — every design page lists "why this choice over alternatives" for each major decision.
- Print the database selection guide — picking the right database is the highest-impact architectural decision.
This is 1 of 11 resources in the Cheatsheet Reference Pro toolkit. Get the complete [System Design Visual Guide] with all files, templates, and documentation for $19.
Or grab the entire Cheatsheet Reference Pro bundle (11 products) for $79 — save 30%.
Top comments (0)