Day4 in System Designing

What is Horizontal Scaling? Horizontal scaling, often referred to as "scaling out," means increasing the capacity of your system by adding more machines (servers) into your infrastructure pool, rather than making a single machine stronger. Instead of trading your delivery truck for a massive semi-truck (vertical scaling), you hire an entire fleet of standard delivery trucks to work together at the same time. In system design, horizontal scaling is the foundation for building highly available, fault-tolerant, and massive global-scale applications. Step 1: Implementing the Fleet Infrastructure To transition a system from a single server to a horizontally scaled architecture, you must introduce components that allow multiple machines to coordinate seamlessly: Load Balancers (The Traffic Cop): You place a load balancer (like Nginx, AWS ALB, or HAProxy) in front of your servers. It intercepts all incoming user requests and distributes them evenly across your fleet of application servers so no single machine gets overwhelmed. Stateless Application Servers: For horizontal scaling to work smoothly, application servers should ideally be "stateless." This means they do not save user session data (like login info or shopping carts) on their local hard drives. If Server A crashes, the load balancer can send the user to Server B without the user getting logged out. Centralized Session Storage: To keep servers stateless, all user sessions are offloaded to a shared, ultra-fast, in-memory data store like Redis or Memcached that all application servers can access. Step 2: Horizontally Scaling the Database Layer While scaling the application servers out is relatively easy, scaling a relational database horizontally is the hardest part of system design. Architects use specific strategies to do this: Read Replicas: You separate read and write traffic. One "Primary" database handles all data changes ( INSERT , UPDATE ), while multiple "Replica" databases handle data viewing ( SELECT ). Database Sharding (Horizontal Partitioning): When data grows too large for one database disk, you break tables into smaller pieces across completely different machines based on a key. For example, users with IDs 1 to 1,000,000 are stored on Database Server 1, and IDs 1,000,001 to 2,000,000 are stored on Database Server 2. NoSQL Databases: Often, architects transition non-relational data to databases designed natively for horizontal scaling (like Cassandra, MongoDB, or DynamoDB), which inherently support distributed data across clusters. Advantages of Horizontal Scaling Infinite Scaling Ceiling: There is no physical hardware limit. If your traffic doubles next month, you don't need to engineer a futuristic processor; you simply boot up more standard, inexpensive servers. High Availability & Fault Tolerance: If you have 10 servers and one breaks down or crashes, the load balancer automatically stops sending traffic to it. Your application stays online, and your users experience zero downtime. Cost Inefficiency Fix (Linear Costs): Standard commodity servers are cheap. Buying ten basic servers is often significantly cheaper than trying to build or buy one ultra-powerful, specialized enterprise server. The Complexities and Disadvantages Horizontal scaling is powerful, but it drastically complicates your software code: Data Consistency Issues (Eventual Consistency): If a user updates their profile picture on the Primary database, it takes a few milliseconds to copy that picture to the Read Replicas. If they refresh their page instantly, they might temporarily see their old picture until the data syncs. Network Latency & Partitions: Because machines must talk to each other over a network to process data, network lag is introduced. Additionally, you must design your system to handle situations where a network switch fails and splits your server fleet in half (Network Partitioning). Architectural Complexity: Your engineering team must write code capable of handling distributed transactions, complex service-to-service communication, and centralized logging. Summary Comparison Feature Vertical Scaling (Scale Up) Horizontal Scaling (Scale Out) Action Make your single server bigger/stronger Add more standard servers to your pool Complexity Extremely simple (No code changes) Complex (Requires Load Balancers & Sharding) Limit Hard hardware ceiling Theoretically infinite Resilience Single Point of Failure (SPOF) Fault-tolerant (High availability)