From Monolith to Microservices: A Complete Journey with Real‑World Examples

01 Initial Requirements

A small team builds a basic online supermarket with a public website for browsing and purchasing, plus an admin backend for managing users, products, and orders.

Website features: user registration/login, product display, order placement.

Admin backend features: user management, product management, order management.

The initial monolithic deployment is simple but limited.

02 Business Growth and Early Problems

Rapid business expansion introduces new marketing features, mobile apps, and data analysis, leading to ad‑hoc code additions, duplicated logic, tangled API calls, unclear service boundaries, performance bottlenecks, shared database issues, and difficult deployments.

03 Need for Change

The team decides to abstract common capabilities into dedicated services: User Service, Product Service, Promotion Service, Order Service, and Data‑Analysis Service, reducing code duplication and centralising data access.

04 Database Splitting

Each service receives its own isolated database, eliminating shared‑database bottlenecks and allowing heterogeneous storage technologies, such as a data‑warehouse for analytics and caches for high‑traffic services.

05 Monitoring – Detecting Fault Signs

Each component exposes a uniform metrics endpoint; a Prometheus collector gathers data, and Grafana visualises it with alerts for memory, latency, error rates, etc.

06 Tracing – Link Tracking

Requests are traced across services using a traceId, spanId, parentId, and timestamps. The team adopts Zipkin (an open‑source Dapper implementation) and injects tracing headers via an HTTP interceptor.

07 Log Analysis

Log aggregation is handled with the ELK stack (Elasticsearch, Logstash, Kibana). Logs are collected by agents on each service and shipped to Logstash for indexing and search.

08 Gateway – Access Control and Service Governance

A gateway sits between callers and services, performing authentication, authorization, and routing. The team uses a coarse‑grained gateway per service group.

09 Service Registration & Discovery – Dynamic Scaling

Services register themselves with a discovery system (e.g., Consul, Eureka, etcd) and obtain peer addresses automatically, enabling effortless scaling and load‑balanced client‑side routing.

10 Circuit Breaking, Service Degradation, and Rate Limiting

When a downstream service fails repeatedly, the circuit breaker opens to prevent cascading failures. Non‑critical features are degraded gracefully, and rate limiting protects services from overload.

11 Testing

Testing is organised into three layers: end‑to‑end tests for critical flows, service‑level tests for APIs, and unit tests for code units, with mock servers used to isolate dependencies.

12 Microservice Framework

The team builds a shared framework that abstracts integration with metrics, tracing, logging, registration, routing, circuit breaking, and rate limiting, reducing boilerplate across services.

13 Service Mesh

Alternatively, a sidecar‑based service mesh (data plane) handles networking while a control plane manages configuration, offering non‑intrusive observability and traffic management at the cost of some performance overhead.

14 Conclusion – Ongoing Evolution

Microservices are not the final destination; future directions include serverless, FaaS, and even revisiting monoliths when appropriate.