Scaling Distributed Systems

When your application grows from 100 users to 100 million, your infrastructure must grow either Up or Out. Understanding the fundamental difference is the first step toward becoming a System Architect.

1. Vertical Scaling (Scaling Up)

Scaling up means adding more power (CPU, RAM, SSD) to an existing server.

• Pros: Simple management, no code changes required.
• Cons: Hard hardware limit (you can only buy a server so big), and it is a **Single Point of Failure** (if the big server dies, the whole app dies).

2. Horizontal Scaling (Scaling Out)

Scaling out means adding more servers to your pool. This requires a Load Balancer to distribute traffic.

• Pros: Infinite scalability, higher availability (if one node fails, others take over).
• Cons: Extremely complex. Requires your application to be Stateless and introduces challenges like data consistency and network latency.

4. Interview Mastery

Q: "Which scaling method would you use for a Relational Database like SQL Server?"

Architect Answer: "Traditionally, we Scale Up (Vertical) databases because they are tightly coupled via ACID transactions and shared state. However, at extreme scale, we must move to **Database Sharding** (Horizontal Scaling), where we split the data across multiple database instances. This is a high-cost architectural decision that should only be made when the biggest available server is no longer enough to handle the write load."