Microservice Architecture Evolution: From Monolith to Service Mesh

This article introduces microservice architecture and its related components, explaining what they are and why they are used, using an online supermarket example to illustrate the transition from a monolithic application to a distributed system.

Initial Requirements

Initially, the founders needed a public website for browsing and purchasing products and a management backend for handling users, products, and orders.

Website

User registration and login

Product display

Order placement

Management backend

User management

Product management

Order management

After a quick implementation, the system was deployed on a cloud service and went live.

Business Growth and Problems

Rapid competition forced the team to add promotions, mobile apps, and data analysis, leading to duplicated code, tangled interfaces, oversized services, performance bottlenecks, and difficult deployments.

Need for Change

Recognizing these issues, the team abstracted common business capabilities into separate public services: User Service, Product Service, Promotion Service, Order Service, and Data‑Analysis Service.

Service Refactoring

Splitting functionality reduced code duplication, but a shared database still caused performance and coupling problems, prompting a full database split and the introduction of a message queue.

Monitoring – Detecting Fault Signs

To catch problems early, the team built a monitoring stack using Prometheus for metric collection and Grafana for visualization, exporting metrics from components such as Redis and MySQL.

Tracing – Locating Issues

Linking user requests across services required distributed tracing. The team adopted Zipkin (an open‑source Dapper implementation), injecting traceId, spanId, parentId, requestTime, and responseTime into HTTP headers.

Log Analysis

Large, distributed logs were centralized with the ELK stack (Elasticsearch, Logstash, Kibana) to enable fast searching and analysis.

Gateway – Access Control and Service Governance

A gateway was placed in front of the services to enforce permissions and provide a unified API surface.

Service Registration & Discovery – Dynamic Scaling

Automatic registration and discovery (e.g., using Consul, Eureka, etc.) allowed new instances to be added without manual load‑balancer configuration.

Circuit Breaker, Degradation, and Rate Limiting

When a service became unresponsive, circuit breaking prevented cascading failures; non‑critical services could be degraded, and rate limiting protected upstream services from overload.

Testing

Testing was organized into three layers: end‑to‑end, service‑level, and unit tests, with mocks used for dependent services.

Microservice Framework

The team built a shared framework to handle metric exposure, tracing, logging, registration, routing, and resilience features, reducing boilerplate across services.

Service Mesh Alternative

Instead of embedding code, a sidecar‑based service mesh (data plane + control plane) was considered, offering non‑intrusive traffic management at the cost of additional latency.

Conclusion

Microservices are not the final architecture; future directions include serverless and occasional returns to monoliths, but the current refactor provides a clearer, more maintainable system.