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 adopted, while focusing on a high‑level view rather than implementation details.

Initial Requirements

A few years ago, two founders built an online supermarket with a simple website for browsing and purchasing products and a separate admin backend for managing users, products, and orders. The initial architecture consisted of a single website and a separate admin system deployed on a cloud server.

Business Growth and Emerging Problems

Rapid competition forced the team to add promotions, a mobile app, and data‑analysis capabilities. The hurried implementation led to duplicated business logic, tangled API calls, blurred service boundaries, performance bottlenecks in the shared database, deployment difficulties, and team friction.

Duplicate code across web and mobile apps.

Inconsistent data sharing via database or API.

Services growing beyond their original responsibilities.

Admin backend becoming a performance bottleneck after adding new features.

Shared database tables causing contention and making schema changes risky.

Complex release process and frequent night‑time deployments.

Team disputes over ownership of common functionality.

First Refactoring: Service Extraction

The team abstracted common business capabilities into independent services: User Service, Product Service, Promotion Service, Order Service, and Data‑Analysis Service. Each backend now consumes these services, reducing redundant code.

Although services were separated, the database remained shared, preserving many monolithic drawbacks.

Second Refactoring: Database Splitting and Messaging

The team isolated each service’s persistence layer, introduced a message queue for real‑time communication, and allowed heterogeneous storage (e.g., a data‑warehouse for analytics, caches for high‑traffic services).

Operational Concerns

With many services, fault isolation becomes hard. The article discusses building a monitoring system (using Prometheus and Grafana), implementing distributed tracing (using Zipkin), and setting up centralized log analysis (ELK stack).

Tracing records traceId, spanId, parentId, request and response times for each HTTP call.

Gateway, Service Discovery, and Resilience

A gateway enforces permission checks and can act as an API portal. Service discovery (e.g., Consul, Eureka, Zookeeper) enables dynamic registration and load‑balancing. The article also covers circuit breaking, service degradation, and rate limiting to protect the system from cascading failures.

Testing Strategy

Testing is divided into end‑to‑end, service‑level, and unit tests, each with increasing difficulty but decreasing coverage. Mock servers help isolate dependencies during service tests.

Microservice Framework vs. Service Mesh

The team built a custom microservice framework to handle metrics, tracing, logging, registration, routing, circuit breaking, and rate limiting. However, framework upgrades are costly. A service mesh (sidecar proxies with a control plane) offers non‑intrusive management, though it may introduce performance overhead.

Conclusion

Microservices are not the final destination; future directions include serverless, FaaS, and even a return to monoliths in some scenarios. The article ends with the authors reflecting on their journey and planning a well‑deserved break.