Core Building Blocks — 12 Fundamental Concepts (Part 5)
Each concept below follows the same structure: What it is → Why it exists → When to use → When NOT to use → Trade-offs → Real examples → Diagram → Beginner mistakes.
The 12 Concept are :
Requirements Clarification (Part 1)
Back-of-Envelope Estimation (Part 1)
Databases — SQL vs NoSQL (Part 2)
Caching (Part 2)
Load Balancing (Part 3)
API Design (Part 3)
Message Queues + Event-Driven Systems (Part 4)
Consistency vs Availability (CAP Theorem) (Part 4)
Scaling Strategies
Fault Tolerance + Reliability
.CDN (Content Delivery Network)
Data Partitioning (Sharding)
But in this article we cover only two concept
9. Scaling Strategies
What it is: How you add capacity to your system as demand grows.
Vertical Scaling (Scale Up):
Add more CPU/RAM to one machine
Simple, no code changes
Hard limit: biggest machine available
Single point of failure remains
Horizontal Scaling (Scale Out):
Add more machines, distribute load
Theoretically unlimited scale
Requires stateless services, shared storage
More complex operationally
When to go vertical first: Small teams, early stage, simple systems. Vertical is simpler.
When to go horizontal: When vertical limit is hit, or when you need fault tolerance.
Stateless vs Stateful services:
Stateless: Any server can handle any request. Easy to scale horizontally.
Stateful: Server holds session/state. Sticky sessions needed. Hard to scale.
Rule: Design services to be stateless. Put state in a shared layer (DB, cache, blob store).
10. Fault Tolerance + Reliability
What it is: System's ability to continue functioning when parts fail.
WHY it exists: Everything fails. Disks fail, networks fail, data centers fail. Design assumes failure.
Key patterns:
| Pattern | What it does |
|---|---|
| Redundancy | Duplicate critical components |
| Replication | Copy data across multiple nodes |
| Failover | Automatically switch to backup |
| Circuit Breaker | Stop calling a failing service to prevent cascade |
| Retry with backoff | Retry failed requests with increasing delays |
| Bulkhead | Isolate failures so they don't spread |
Availability math:
99% uptime = 87.6 hours downtime/year
99.9% = 8.7 hours/year
99.99% = 52 minutes/year
99.999% (five nines) = 5 minutes/year
Replication types:
Synchronous: Primary waits for replica to confirm. No data loss, slower.
Asynchronous: Primary doesn't wait. Faster, but replica may lag.
Beginner mistake: Designing only the happy path. Always ask: 'What happens when the database goes down? When the cache is empty? When the queue is full?'
