How Software Architecture Evolves from Monolith to Cloud‑Native Microservices

Architecture Evolution

Software architecture typically progresses through three phases: early (monolithic), growth (scaled), and stable (microservice).

Early (Monolithic) Architecture

In the early stage a single server‑side component and a relational database are built using a three‑layer MVC pattern. Common technology choices are:

Backend: Spring MVC or Spring Boot

Frontend: Vue (often with a front‑end/back‑end separation)

Database: MySQL

Cache: Redis

Static resource hosting: Nginx

Cache access follows the flow: request → check Redis → if hit, return data → if miss, query MySQL → update Redis. High availability is achieved by deploying multiple Redis nodes, providing 99‑99.9% uptime.

Growth‑Stage Architecture

When daily active users reach tens of thousands the system must remain stable while supporting rapid product iteration. Key techniques include:

Frontend acceleration via CDN or dedicated domains.

Horizontal scaling of backend services using layer‑4 or layer‑7 load balancers.

Database optimization for both structured and unstructured data, complemented by caching.

Cache layer is expanded with Redis Cluster , which uses a decentralized hash‑slot design. New nodes are added with the redis-trib tool, migrating slots without service interruption. Data scaling initially uses sharding (split tables) and later adopts distributed databases for true horizontal scaling.

Message middleware such as RabbitMQ decouples services, provides asynchronous delivery and traffic shaping.

Stable (Microservice) Architecture

In the stable phase functionality is split into independent services to achieve “divide and conquer”. Core tasks are:

Business splitting based on data independence.

Unified configuration management.

Distributed scheduled task handling.

Cloud‑Native Architecture

Cloud‑native design emphasizes non‑functional requirements: fault isolation, tolerance, automatic recovery, elastic resource usage, and cross‑datacenter high availability (targeting up to 99.9999999% data availability).

Continuous Delivery

Continuous delivery automates requirement changes, iteration, and deployment. DevOps integrates development, testing, and operations to achieve end‑to‑end automation.

Architecture Design Details

Business Splitting

Principle: high cohesion, low coupling. The typical workflow is:

Define business boundaries, primarily based on data independence.

Assign each business its own independent database.

Develop each business in a separate codebase/project.

Choose communication style – synchronous RESTful APIs, asynchronous message queues, or a hybrid.

Deploy services independently.

Microservice Design

Key aspects include service discovery, governance, framework selection, orchestration, and testing.

Service Discovery

Two models exist:

Server‑side discovery : DNS or VIP‑based load balancers provide a stable endpoint.

Client‑side discovery : Services query a registry (e.g., ZooKeeper or Consul) to obtain current instance addresses.

Service Governance

Governance covers the whole service lifecycle. Two common mechanisms are:

Elastic scaling : Kubernetes Horizontal Pod Autoscaler (HPA) monitors pod CPU/memory metrics and adjusts replica counts automatically.

Circuit breaking : Isolates failing nodes to prevent cascading failures (e.g., fallback when a payment service is down).

Frameworks

Spring Cloud (built on Spring Boot) provides distributed configuration, Eureka service registration, Zuul routing, Ribbon client‑side load balancing, Hystrix circuit breaker, and messaging.

Dubbo – high‑throughput RPC framework from Alibaba, ideal for long‑lived, low‑payload calls; less suitable for complex asynchronous workflows.

Service Orchestration

Container orchestration with Docker + Kubernetes defines scaling policies, gray releases, rolling upgrades, and resource allocation for each microservice.

Testing

Comprehensive testing includes unit, interface, integration, and system tests. Mocks are used to simulate dependent services, allowing isolated verification of each microservice.

Unified Configuration Center

A configuration center centralizes settings such as database connections, cache parameters, queue definitions, and runtime thresholds, enabling consistent updates across all services as the system scales.

Distributed Scheduled Tasks

Distributed scheduling must provide high availability, elastic scaling, and unified management. Two models are commonly used:

Preemptive scheduling : Each worker competes for tasks from the scheduler. Simple to implement but can cause excessive polling.

Assignment scheduling : A single master node assigns tasks to workers using a distributed lock (ZooKeeper or Redis). If the master fails, a new master is elected.

Open‑source frameworks:

Quartz – widely used, supports clustering via pessimistic locks.

Chronos – leader‑based scheduling with a web UI, supports ISO8601 recurrence.

Kubernetes Scheduled Jobs – native cron‑like jobs managed by the Kubernetes control plane.