From Standalone to Cloud Native: The Logic, Drivers, and Lessons of Internet Architecture Evolution#
Introduction: Architecture Is Essentially About Solving Business Problems#
In the field of internet technology, architecture evolution is a perennial topic. Many junior developers enter the industry working with microservices and container orchestration, lacking a historical perspective on “why architecture looks the way it does today.” In reality, every evolution of internet architecture is not some technical virtuosity conjured out of thin air, but an inevitable outcome of business growth forcing technological upgrades.
“Each stage of change is driven by business needs, addressing specific performance, availability, or maintainability challenges.”
Understanding this evolutionary journey not only deepens our grasp of the design philosophies behind today’s cloud-native technologies but also sharpens our judgment when confronting new paradigms in the future.
Phase 1: Monolithic Architecture – Everything Starts Simple#
In the early days of internet entrepreneurship, business models were typically uncomplicated and team sizes were small. The architectural form at this stage was the classic monolithic application: a single project containing all functional modules, ultimately packaged into a WAR or JAR file and deployed on a server consisting of Tomcat (application server) + MySQL (database).
Characteristics and Advantages#
| Characteristic | Description |
|---|---|
| High development velocity | For small teams, no need to contend with distributed complexity; rapid iteration to validate business models |
| Simple deployment | Just drop a single package into the container and start it |
| Low cost | A single server hosts everything, keeping infrastructure and operational costs minimal |
Hidden Risks#
All code is coupled together. As the business codebase expands, maintenance costs rise exponentially. Any change to a single line of code requires full regression testing and a complete redeployment of the entire application.
Phase 2: Separation of Application Server and Database – Solving “Can’t Handle the Load” and “Running Too Slow”#
When business begins to grow and user traffic gradually increases, two bottlenecks in the monolithic architecture emerge first:
- Performance bottleneck: High request volume strains application server CPU and memory
- Database bottleneck: Database connections are exhausted, and query response times degrade
Evolutionary Driver#
Resolve contention for compute and data resources.
Solution#
Physically separate the application server (Tomcat) from the database server (MySQL), deploying them on different machines. This way, the application server focuses exclusively on business logic while the database server handles data storage and queries, with no interference between them.
Lesson#
This is the first step in architectural decoupling: physical separation is the most direct and effective means of resolving resource contention.
Phase 3: Introducing Local Caching and Distributed Caching – Relieving Database Pressure#
As user traffic grows further, the database becomes the new bottleneck. Every request queries the database, even for the exact same data.
Evolutionary Driver#
Reduce direct database access and lower database I/O pressure.
Solution#
| Approach | Advantages | Disadvantages |
|---|---|---|
| Local cache (e.g., Ehcache) | Extremely fast access | Limited capacity; cache inconsistency across servers |
| Distributed cache (Redis/Memcached) | Handles extremely high QPS, effectively protects the underlying database | Introduces middleware, increasing system complexity |
Distributed caching became the mainstream choice at this time, capable of sustaining extremely high QPS while shielding the database.
Lesson#
Introducing middleware marks the beginning of architectural complexity, yet also lays the groundwork for future horizontal scaling.
Phase 4: Reverse Proxy and Load Balancing – From “Solo” to “Team Effort”#
A single application server always has a performance ceiling. When a single machine’s processing capacity is exhausted, horizontal scaling is required to improve overall throughput.
Evolutionary Driver#
Add more machines to linearly increase system processing capacity and address high-concurrency challenges.
Solution#
- Deploy Nginx as a reverse proxy server, serving as the traffic entry point that receives all user requests
- Configure load-balancing strategies (e.g., round-robin, weighted round-robin, least connections, etc.) to distribute requests across multiple back-end application server nodes
At this point, the database and cache become shared resources, and application servers become stateless nodes.
Lesson#
Statelessness is a prerequisite for horizontal scaling. This means application servers cannot store user session data locally; sessions must be offloaded to external storage such as Redis.
Phase 5: Read-Write Separation and Sharding – The Database “Evolves”#
After application servers are scaled horizontally, database pressure does not diminish—in fact, it intensifies due to the increased number of connections. At this stage, the database becomes the most fragile link in the entire system.
Evolutionary Driver#
Address database read/write performance bottlenecks and storage capacity constraints.
Solution#
| Approach | Description | Use Case |
|---|---|---|
| Read-write separation | Master handles writes, slaves handle reads; data is replicated via master-slave sync | Read-heavy, write-light scenarios |
| Sharding | Vertical (split by business domain) and horizontal (split by ID hashing, etc.) | Tables reaching tens of millions or hundreds of millions of rows |
Lesson#
Database refactoring is one of the most complex and riskiest aspects of architecture evolution, often requiring data-routing logic to be designed at the application layer in advance.
Phase 6: Introducing ES and Search Engines – Tackling “Complex Query” Challenges#
Even with sharding, relational databases (MySQL) still struggle with complex scenarios like fuzzy search, multi-condition combination queries, and the like.
Evolutionary Driver#
Provide millisecond-level complex query and full-text search capabilities over massive datasets.
Solution#
Introduce Elasticsearch (ES) as a search engine. Use middleware like Canal to synchronize MySQL data changes (inserts, updates, deletes) to ES in real time, with business logic querying directly from ES.
Lesson#
This marks the emergence of the CQRS (Command Query Responsibility Segregation) pattern in embryonic form: writes and reads use different data models, each optimized for peak performance.
Phase 7: Microservices – From “Big and All-Encompassing” to “Small and Specialized”#
By now, the system can support high concurrency, but internally the application remains a tightly coupled monolith. As the team grows to dozens or even hundreds of engineers, issues like code conflicts, deployment queues, and “touching one part breaks the whole” become acute.
Evolutionary Driver#
Conway’s Law in action—system architecture mirrors organizational communication structures. To enable agile development and team autonomy, splitting is mandatory.
Solution#
- Decompose the monolithic application into multiple independent services along business boundaries
- Each service owns its own database and independent deployment pipeline
- Services communicate via RPC (e.g., Dubbo) or HTTP RESTful APIs
- Introduce a service registry (e.g., Nacos, Consul) for automatic service discovery and health checking
Lesson#
Microservices solve team collaboration efficiency problems but introduce new challenges: distributed transactions, service call-chain tracing, and API version management.
Phase 8: Containerization and Cloud Native – Toward “Elasticity and Automation” as the Ultimate Form#
Microservices lead to an explosion in the number of services (hundreds or even thousands). Traditional manual deployment and operations practices can no longer keep up.
Evolutionary Driver#
The complexity of microservice governance forces an upgrade in operations systems, pursuing elasticity, portability, and automation.
Solution#
| Technology | Role | Core Value |
|---|---|---|
| Docker (containerization) | Packages applications and dependencies into standardized images | Build once, run anywhere |
| Kubernetes (container orchestration) | Automates deployment, rolling updates, auto-scaling, and self-healing | Large-scale cluster management |
| Istio (Service Mesh) | Offloads service-to-service communication, circuit breaking, rate limiting, and observability to the infrastructure layer | Frees business developers from these concerns |
Lesson#
Cloud native is not merely a technology-stack upgrade, but a comprehensive transformation of development processes (DevOps) and organizational culture (SRE).
Conclusion: The Core Logic of Architecture Evolution#
Looking back on this journey, we can clearly discern a single thread:
The scale of the business determines the complexity of the architecture; architecture evolution is an “adaptive” response to the pace of business growth.
| Phase | Core Problem | Target Outcome |
|---|---|---|
| 0–2 | Resource bottlenecks | Separation and scaling of compute and storage resources |
| 3–5 | Performance bottlenecks | Optimization of concurrency and query performance |
| 6–7 | Development efficiency bottlenecks | Team collaboration and delivery velocity |
| 8 | Operations efficiency bottlenecks | Large-scale cluster management |
For every engineer, there is no “silver bullet” ultimate architecture. The architecture that best fits the current business stage, team size, and cost budget is the right one. More importantly, it is essential to understand the trade-offs behind each step—introducing new technology solves old problems while inevitably bringing new ones.