How System Architecture Evolves: From Single-Server LAMP to Distributed Services

1. Initial Stage: Monolithic LAMP Architecture

In the earliest phase, all resources—application code, database, and files—are deployed on a single server, commonly referred to as a LAMP stack (Linux, Apache, MySQL, PHP). This low‑cost setup uses free open‑source components and is suitable for small‑scale systems.

2. Separation of Application and Data Services

As traffic grows, a single server becomes a bottleneck. The solution is to split the application layer and the database layer onto separate machines, improving concurrency handling and storage capacity.

3. Introducing Caching for Performance

To reduce database load, a small portion of frequently accessed data is stored in a cache server. This follows the 80/20 rule: 80% of requests target 20% of data. Both local (in‑process) and remote distributed caches are used, each with trade‑offs in speed and capacity.

4. Application Server Clustering

After sharding databases, the system still experiences slowdowns due to request queuing on the web server. Deploying multiple web servers behind a load balancer distributes traffic, increases concurrent processing capacity, and prevents any single node from becoming a bottleneck.

5. Database Read/Write Splitting

When write, update, and delete operations contend for database connections, performance degrades. Introducing multiple database servers with load‑balanced read/write splitting alleviates the pressure, allowing the system to scale further.

6. Reverse Proxy and CDN Acceleration

To cope with diverse network conditions and geographically dispersed users, a CDN and reverse‑proxy layer cache static content and route requests, reducing latency and offloading traffic from origin servers.

7. Distributed File System and Distributed Database

When data volume outgrows a single server’s capacity, the system adopts distributed databases and distributed file systems. Full‑scale sharding (both database and table) becomes necessary only after business‑level sharding (separate databases per business domain) is exhausted.

8. Adoption of NoSQL and Search Engines

Complex business requirements demand flexible storage and fast retrieval. Introducing NoSQL databases and dedicated search engines addresses these needs, while a unified data‑access layer in the application server abstracts the multiple back‑ends.

9. Business‑Level Splitting

The system is refactored by separating functionalities into distinct business lines. Applications are deployed per business domain, communicating via hyperlinks, message queues, or shared data stores. Two splitting strategies are described:

Vertical splitting: Break a large monolith into several smaller, relatively independent web applications.

Horizontal splitting: Extract reusable services into distributed components, defining clear service interfaces and dependency contracts.

10. Distributed Services

As business modules become increasingly granular, a common set of application modules is extracted and deployed as shared services on distributed servers. This mitigates database connection exhaustion and prevents denial‑of‑service scenarios caused by excessive inter‑service coupling.