From Single Server to Global Scale: 14 Stages of Backend Architecture Evolution

Basic Concepts

Distributed: Multiple modules deployed on different servers, e.g., Tomcat and databases on separate machines.

High Availability: System continues to serve when some nodes fail.

Cluster: A group of servers acting as a single service, with automatic failover.

Load Balancing: Evenly distributing requests across nodes.

Forward and Reverse Proxy: Forward proxy handles outbound traffic from internal systems; reverse proxy handles inbound traffic and forwards it to internal servers.

Architecture Evolution

1. Single‑Machine Architecture

Initially, Tomcat and the database run on the same server. As traffic grows, resource contention makes this setup insufficient.

2. First Evolution – Separate Tomcat and Database

Deploy Tomcat and the database on separate servers, eliminating resource competition and improving performance. Database read/write becomes the next bottleneck.

3. Second Evolution – Add Local and Distributed Caches

Introduce local caches (e.g., memcached) and a distributed cache (e.g., Redis) to store hot items and HTML pages, dramatically reducing database load. Cache‑related issues such as consistency, penetration, and avalanche are introduced.

4. Third Evolution – Reverse Proxy for Load Balancing

Deploy multiple Tomcat instances behind a reverse proxy (Nginx or HAProxy). This spreads traffic across many application servers, but the database remains a bottleneck.

5. Fourth Evolution – Database Read‑Write Separation

Split the database into read and write instances, using middleware such as MyCAT to synchronize data. This improves read scalability but introduces data consistency challenges.

6. Fifth Evolution – Business‑Based Database Sharding

Allocate different business domains to separate databases, reducing cross‑business contention. This improves scalability at the cost of cross‑database queries.

7. Sixth Evolution – Split Large Tables into Small Tables

Hash‑based routing or time‑based partitioning creates many smaller tables, enabling horizontal scaling. Middleware like MyCAT assists with routing and access control. This approach turns the system into a distributed MPP database.

8. Seventh Evolution – LVS or F5 Load Balancing

Introduce layer‑4 load balancers (LVS software or F5 hardware) to handle massive TCP traffic, with keepalived providing high‑availability IP failover.

9. Eighth Evolution – DNS Round‑Robin for Data‑Center Load Balancing

Configure DNS to return multiple IPs for a domain, distributing traffic across different data centers and achieving geographic scalability.

10. Ninth Evolution – Add NoSQL and Search Engines

When relational databases can no longer handle complex queries or massive data, integrate HDFS, HBase, Redis, Elasticsearch, Kylin, Druid, etc., to address specific workloads.

11. Tenth Evolution – Split Monolithic Application into Smaller Services

Divide the codebase by business modules, using a distributed configuration center (e.g., ZooKeeper) for shared settings.

12. Eleventh Evolution – Extract Shared Functions as Microservices

Common capabilities (user management, orders, authentication) become independent services accessed via HTTP, TCP, or RPC, managed with frameworks like Dubbo or Spring Cloud.

13. Twelfth Evolution – Introduce an Enterprise Service Bus (ESB)

Use an ESB to unify protocol conversion and service interaction, reducing coupling and aligning with SOA principles.

14. Thirteenth Evolution – Containerization

Package services as Docker images and orchestrate them with Kubernetes, enabling rapid deployment, scaling, and isolation.

15. Fourteenth Evolution – Cloud Platform Adoption

Move the system to a public cloud (IaaS/PaaS/SaaS), leveraging elastic resources, Docker/K8s, and managed big‑data components to achieve on‑demand scaling and lower operational costs.

Architecture Design Summary

The evolution path presented is illustrative; real‑world systems may need to address multiple bottlenecks simultaneously or follow a different order based on business priorities.

Design should meet current performance targets while leaving room for future expansion. For continuously growing platforms (e.g., e‑commerce), architecture must anticipate the next growth phase.

Service‑side architecture differs from big‑data architecture: the former focuses on application organization, while the latter provides the underlying storage, processing, and analytics capabilities.

Key Design Principles

N+1 design – eliminate single points of failure.

Rollback capability – ensure forward compatibility and safe version rollback.

Feature toggle – allow rapid disabling of problematic functions.

Monitoring – embed observability from the design stage.

Multi‑active data centers – achieve high availability across locations.

Use mature, battle‑tested technologies.

Resource isolation – prevent one business from monopolizing resources.

Horizontal scalability – design for scale‑out to avoid bottlenecks.

Buy non‑core components when appropriate.

Commercial‑grade hardware – improve reliability.

Rapid iteration – develop small features quickly for early feedback.

Stateless services – avoid reliance on previous request state.

Author: huashiou Source: https://segmentfault.com/a/1190000018626163