From Moore's Law to Distributed Architecture: Load Balancing, Session Management, and Database Sharding

Moore's Law states that the number of transistors on an integrated circuit doubles roughly every 18‑24 months, doubling performance at constant cost, but this trend is ending due to heat and physical limits, creating a performance bottleneck for single machines and prompting the need for distributed high‑availability solutions.

A distributed system consists of multiple nodes (computers) connected by a network, with software deployed across these nodes to work collaboratively.

In a distributed environment, input/output changes: each node can act as an I/O device when receiving data from other nodes, while traditional human‑machine I/O devices remain.

Control also changes: a central controller (hardware or software load balancer) coordinates requests among nodes, performing load balancing and routing.

Traditional monolithic applications follow a simple MVC chain (Controller → Service → DAO) and are packaged into a single Tomcat instance; as traffic grows, a single machine becomes insufficient.

Introducing a load balancer (e.g., Nginx) and serving static assets separately allows multiple Tomcat servers to handle business logic, but creates session consistency challenges across servers.

Session Sticky keeps a user's requests on the same web server, but if that server fails the session is lost, requiring the user to log in again and adding overhead for session mapping.

Session Replication synchronizes session data between servers; however, it incurs network overhead proportional to session changes and consumes memory on each server as the cluster grows.

Session centralized management reduces inter‑server synchronization but adds latency; it still suffers from single‑point failure risks.

To handle increasing read‑heavy workloads, read/write separation is employed: read requests go to a replica database (dbForRead) while writes go to the master; MySQL master‑slave setups may cause inconsistency, mitigated by group replication in newer versions.

Because relational databases have limitations, distributed storage systems (distributed file systems, key‑value stores, and distributed databases) are introduced to complement them.

When business logic is vertically or horizontally split, challenges arise such as SQL routing, primary‑key generation across multiple databases, and complex cross‑database queries, especially for pagination.

Service‑oriented architecture, search capabilities, and message queues are adopted to decouple components and enable asynchronous processing.

The evolution described culminates in the final system architecture diagram illustrating the distributed, load‑balanced, and sharded backend design.