📐 System Design: Scalability, Load Balancing & High Availability
1️⃣ Principles of Scalability: Vertical vs Horizontal Scaling
Definition: Scalability kisi system ki wo inherent ability hai jisme system increasing workload (traffic, data volume, transaction throughput) ko additional computational resources add karke bina performance degradation ke smoothly handle karta hai.
| Criteria | Vertical Scaling (Scale-Up) | Horizontal Scaling (Scale-Out) |
|---|---|---|
| Core Action | Existing server me zyada RAM, CPU cores ya faster NVMe attach karna. | Application architecture me multiple commodity server nodes add karna. |
| Hardware Ceiling | Hard physical limit hoti hai (Single motherboard CPU/RAM socket limit). | Virtually infinite: Cluster me hazaron nodes linearly add ho sakte hain. |
| Downtime & Cost | Hardware upgrade ke dauran downtime mandatory hota hai; costs exponentially badhti hain. | Zero downtime: Dynamic auto-scaling; linear cost structure. |
| Architecture Complexity | Simple; code changes ki zaroorat nahi padti. | Stateless microservices, distributed caching, aur data partitioning require karta hai. |
2️⃣ Load Balancing Algorithms & L4 vs L7 Routing
Incoming traffic ko backend server pool me evenly distribute karne ke standard computational algorithms:
| Algorithm | Distribution Mechanism | Ideal Use Case |
|---|---|---|
| Round Robin | Requests sequentially har server ko turn-by-turn bhejta hai. | Identical server specs aur homogeneous short-lived requests. |
| Weighted Least Connections | Current active connections count karta hai aur sabse kam load wale heavy server ko assign karta hai. | Long-lived persistent connections (WebSockets, database pools). |
| IP Hash / Client Affinity | Client IP ka hash calculate karke hamesha same backend server par route karta hai. | Sticky sessions jahan local in-memory session persistence maintain karni ho. |
Layer 4 (Transport) vs Layer 7 (Application) Load Balancing:
• L4 (e.g. AWS NLB, HAProxy TCP mode): Sirf IP address aur TCP/UDP port ke basis par ultra-fast routing karta hai (Zero packet inspection; millions of packets/sec).
• L7 (e.g. AWS ALB, NGINX, Envoy): Full HTTP packet parse karta hai (URI path, cookies, HTTP headers). Path-based routing (
• L4 (e.g. AWS NLB, HAProxy TCP mode): Sirf IP address aur TCP/UDP port ke basis par ultra-fast routing karta hai (Zero packet inspection; millions of packets/sec).
• L7 (e.g. AWS ALB, NGINX, Envoy): Full HTTP packet parse karta hai (URI path, cookies, HTTP headers). Path-based routing (
/api/jobs vs /api/users) aur SSL termination provide karta hai.
3️⃣ Consistent Hashing & Virtual Nodes
Traditional modulo hashing (server_index = hash(key) % N) me jab ek server add ya remove hota hai, toh lagbhag 100% keys reshuffle ho jaati hain, jisse mass cache stampede hota hai. Consistent Hashing keys ko ek conceptual 360° circular ring ($[0, 2^{32}-1]$) par map karta hai:
The Ketama Algorithm:
• Keys aur Servers dono same mathematical ring par hash hote hain.
• Key us server par store hoti hai jo ring par clockwise direction me sabse pehle milta hai.
• Node Addition / Failure Impact: Jab naya node add hota hai, toh sirf $K/N$ keys move hoti hain ($K$ = total keys, $N$ = total nodes), baaki saari keys completely undisturbed rehti hain.
• Virtual Nodes (Vnodes): Data hotspots aur non-uniform distribution prevent karne ke liye har physical server ke multiple virtual replica points (e.g. 100-250 hashes per node) ring par place kiye jaate hain.
• Keys aur Servers dono same mathematical ring par hash hote hain.
• Key us server par store hoti hai jo ring par clockwise direction me sabse pehle milta hai.
• Node Addition / Failure Impact: Jab naya node add hota hai, toh sirf $K/N$ keys move hoti hain ($K$ = total keys, $N$ = total nodes), baaki saari keys completely undisturbed rehti hain.
• Virtual Nodes (Vnodes): Data hotspots aur non-uniform distribution prevent karne ke liye har physical server ke multiple virtual replica points (e.g. 100-250 hashes per node) ring par place kiye jaate hain.
Live Consistent Hashing Ring & Key Rebalance Simulator
[Consistent Hash Ring Engine]: Active Ring: [Node-A @ hash:100, Node-B @ hash:500] | Key Space: [0 - 1000]. Ready...
4️⃣ Theoretical Tradeoffs: CAP & PACELC Theorems
| Pillar | Definition in Distributed Systems |
|---|---|
| Consistency (C) | Har read request latest write return karti hai ya error return karti hai (Linearizability). |
| Availability (A) | Har non-failing node request aane par valid non-error response deliver karta hai (bina latest write ki guarantee ke). |
| Partition Tolerance (P) | Network cable cut ya router drop se network partitions aane par bhi system operational rehta hai (Mandatory in cloud networks). |
The PACELC Theorem (Beyond CAP): Network Partition ($P$) aane par trade-off Availability ($A$) vs Consistency ($C$) ke beech hota hai; Else ($E$) normal operations me trade-off Latency ($L$) vs Consistency ($C$) ke beech hota hai.
# Distributed Database Classifications:
• CP Systems (e.g. HBase, CockroachDB, MongoDB primary): Partition par writes block kar denge consistency maintain rakhne ke liye.
• AP Systems (e.g. Apache Cassandra, DynamoDB eventual): Partition par stale data serve karenge availability maintain rakhne ke liye.
• PA/EL (e.g. DynamoDB default): Partition me Available, Normal me Latency-optimized.
• PC/EC (e.g. Spanner): Partition me Consistent, Normal me Consistent (trades latency).5️⃣ Database Scaling: Replication vs Sharding
| Scaling Strategy | How It Works | Best Used For |
|---|---|---|
| Read Replicas (Master-Replica) | Writes single Master DB par hoti hain; async replication se multiple read-only replicas sync hote hain. | Read-heavy workloads (e.g. 95% reads, 5% writes jaise job boards, news portals). |
| Vertical Partitioning (Federation) | Tables ko business domains ke basis par alag-alag databases me todna (Users DB vs Billing DB). | Microservice boundary alignment. |
| Horizontal Sharding | Single large table ki rows ko multiple distinct databases me distribute karna Shard Key ke basis par (e.g. user_id % 4). |
Massive write throughput aur multi-terabyte tables jahan single disk capacity exceed ho jaye. |
6️⃣ High Availability: Topologies & Split-Brain Defenses
| HA Topology | Traffic Routing | Failover Speed & Cost |
|---|---|---|
| Active - Passive (Warm Standby) | 100% traffic Primary par jata hai; Secondary standby mode me database replication listen karta hai. | Failover time: 30 - 60 seconds (DNS/VIP switch). Cost-efficient. |
| Active - Active (Multi-Master) | Traffic load balancer dwara simultaneously dono instances par distribute hota hai. | Failover time: 0 seconds (Instantaneous). Requires conflict-resolution logic. |
Split-Brain Problem: Jab do redundant master nodes ke beech internal heartbeat network disconnect ho jata hai, toh dono nodes assume kar lete hain ki doosra node dead hai aur dono simultaneous writes accept karna shuru kar dete hain, jisse permanent data corruption hota hai.
Mitigation (Quorum Consensus): Hamesha odd number of nodes (minimum 3 nodes) configure karein. Node sirf tabhi master ban sakta hai jab use cluster ka majority vote ($Q = \lfloor N/2 \rfloor + 1$) prapt ho (Raft / Paxos protocol).
Mitigation (Quorum Consensus): Hamesha odd number of nodes (minimum 3 nodes) configure karein. Node sirf tabhi master ban sakta hai jab use cluster ka majority vote ($Q = \lfloor N/2 \rfloor + 1$) prapt ho (Raft / Paxos protocol).
7️⃣ Disaster Recovery Metrics & Chaos Engineering
The Two Essential DR SLA Metrics:
• RTO (Recovery Time Objective): Outage aane ke baad system ko wapas live karne me maximum kitna time lag sakta hai (Downtime tolerance limit, e.g. RTO ≤ 15 minutes).
• RPO (Recovery Point Objective): Disaster aane par maximum kitne duration ka transaction data permanently loose hona acceptable hai (Data loss tolerance limit, e.g. RPO ≤ 5 minutes of writes).
• RTO (Recovery Time Objective): Outage aane ke baad system ko wapas live karne me maximum kitna time lag sakta hai (Downtime tolerance limit, e.g. RTO ≤ 15 minutes).
• RPO (Recovery Point Objective): Disaster aane par maximum kitne duration ka transaction data permanently loose hona acceptable hai (Data loss tolerance limit, e.g. RPO ≤ 5 minutes of writes).
Chaos Engineering: Production cluster me intentionally random server kill karna (e.g. Netflix Chaos Monkey), network latency inject karna ya region blackhole simulate karna taaki system ki automated recovery pipelines verify ho sakein.
