TechBlueprints Quick Reference
Add more power to existing machine
Best for: Databases, quick wins
Add more machines
Best for: Stateless services, high traffic
| Algorithm | How It Works | Best For |
|---|---|---|
| Round Robin | Rotate through servers sequentially | Similar capacity servers |
| Weighted Round Robin | More traffic to higher-weight servers | Mixed server capacities |
| Least Connections | Route to server with fewest active connections | Long-lived connections |
| IP Hash | Same IP always routes to same server | Session affinity needed |
| Random | Random server selection | Simple, statistically even |
| Type | How It Works | Trade-offs |
|---|---|---|
| Primary-Replica (Master-Slave) | Writes → Primary Reads → Replicas | Read scalability Replica lag, write bottleneck |
| Multi-Primary (Multi-Master) | Any node accepts writes Conflict resolution needed | Write availability Conflict complexity |
| Synchronous | Wait for replicas before ack Strong consistency | No data loss Higher latency |
| Asynchronous | Ack immediately, replicate later Eventual consistency | Low latency Possible data loss |
Cache static content at edge locations
→ Lower latency, reduce origin load
Decouple producers and consumers
→ Handle traffic spikes, async processing
Split into independent services
→ Scale bottlenecks independently
Separate read and write models
→ Optimize each path independently
Replicate DB for read queries
→ Scale reads without sharding
Reuse DB connections
→ Reduce connection overhead
"For scaling this system, I'd first ensure the application layer is stateless so we can horizontally scale with a load balancer. For the database, I'd start with read replicas for [read-heavy workload]. If we need to scale writes, I'd consider sharding by [user_id/geo] using [hash-based] partitioning."