From Monolith to Microservices: A Complete Evolution Guide

01 Initial Requirements

The story starts with Xiao Ming and Xiao Pi building a basic online supermarket: a public website for browsing and purchasing goods, and a separate admin backend for managing users, products, and orders.

02 Business Growth and Early Problems

Rapid competition forces the team to add promotions, mobile apps, and data analysis. Under tight deadlines they cram new features into the existing monolith, resulting in duplicated code, tangled API calls, blurred service boundaries, performance bottlenecks, a single shared database, and difficult deployments.

03 Recognizing the Need for Change

Realizing that short‑term fixes lead to long‑term pain, the team abstracts common business capabilities into dedicated services: User, Product, Promotion, Order, and Data‑Analysis services.

04 Service Isolation with Shared Database

Each service now calls the shared database, which still creates performance hotspots, single‑point failures, and schema coupling across services.

05 Database Sharding and Messaging

To eliminate the shared‑database drawbacks, the team gives each service its own database and introduces a message‑queue layer for real‑time communication.

06 Monitoring – Detecting Fault Signs

Because a distributed system generates many metrics, each component exposes a uniform /metrics endpoint. Prometheus scrapes these endpoints, and Grafana visualises the data and sends alerts.

07 Distributed Tracing

Trace IDs, span IDs, parent IDs, and timestamps are injected into HTTP headers. Zipkin (an open‑source Dapper implementation) collects the traces, allowing engineers to see request trees and pinpoint slow or failing services.

08 Log Analysis

Log volume grows beyond manual inspection, so the team adopts the ELK stack (Elasticsearch, Logstash, Kibana). Logs are shipped to Logstash via agents, indexed in Elasticsearch, and queried through Kibana.

09 API Gateway and Service Governance

A gateway sits between callers and services, performing authentication, request routing, and documentation. The team chooses a coarse‑grained gateway per business domain.

10 Service Registration, Discovery, and Auto‑Scaling

Services register themselves with a discovery system (e.g., Consul, Eureka, etcd). Clients fetch the address list locally, enabling load balancing, version‑aware routing, and dynamic scaling without manual IP updates.

11 Resilience Patterns – Circuit Breaker, Degradation, Rate Limiting

When a downstream service fails repeatedly, a circuit breaker trips to return errors immediately. Non‑critical services are degraded to preserve core functionality. Rate limiting protects overloaded services, optionally per caller.

12 Testing Strategy

End‑to‑end tests cover critical user flows.

Service‑level tests validate API contracts.

Unit tests verify individual code units.

Failures in higher‑level tests are broken down into unit tests for faster feedback.

13 Microservice Framework

The team builds a shared framework that handles metric exposure, tracing hooks, log forwarding, service registration, and routing, reducing boilerplate across services. However, framework upgrades require coordinated releases.

14 Service Mesh (Sidecar)

Instead of embedding cross‑cutting concerns in each service, a sidecar proxy (e.g., Envoy) handles networking. The data plane (sidecars) processes traffic, while a control plane manages configuration, offering non‑intrusive upgrades at the cost of additional memory copies.

15 Ongoing Evolution

Microservices are not the final step; the team looks toward serverless, FaaS, and even revisits monolith ideas, acknowledging that architecture continuously evolves.