system-design

system-design

Overview

A brief summary of what the skill does and its core philosophy.

When to Use

Context for when this skill is applicable.

Rules & Patterns

Based on donnemartin/system-design-primer — the most starred system design resource on GitHub.

Core Principle

Everything is a trade-off. Before writing a single line of backend code, reason through the system at scale. A flat monolith that works now fails at 10× load.

---

Mandatory Pre-Design Checklist

Before architecting any backend system, answer these questions:

1. Scale: What is the expected QPS (queries per second)? Peak vs average?
2. Data volume: How much data? Growth rate? 1GB? 1TB? 1PB?
3. Consistency vs Availability: Can we tolerate eventual consistency? (CAP theorem)
4. Read/Write ratio: Is it read-heavy (cache it!) or write-heavy (shard it!)?
5. Latency requirements: Real-time (<100ms)? Near-real-time (<1s)? Batch?
6. Global distribution: Single region or multi-region?
7. Deployment model: Traditional servers, Serverless, or Edge functions?

---

Core Architecture Patterns

Load Balancing

Clients → Load Balancer → [App Server 1, App Server 2, App Server N]

• Use Round Robin for stateless services
• Use Least Connections for varying request times
• Use IP Hash for session affinity (or move sessions to Redis)
• Always add health checks — remove unhealthy nodes automatically

Rule: Any service expecting > 1000 RPS needs a load balancer. No exceptions.

Caching Strategy

App → [Cache Layer: Redis/Memcached] → Database

Cache decision ladder (check in order):

1. Is it read > write? → Cache it
2. Is it expensive to compute? → Cache it
3. Is it user-specific? → Cache with user key
4. Is it global? → Shared cache, shorter TTL

Cache patterns:

• Cache-aside (lazy loading): check cache → miss → load DB → write cache
• Write-through: write to DB AND cache simultaneously (consistency > performance)
• Write-behind: write to cache → async flush to DB (performance > consistency)