Microservice Architecture Evolution: From Monolith to Service Mesh

1. Initial Requirements

A small team builds a basic online‑store website and an admin backend with user registration, product browsing, ordering, and basic management functions.

2. Business Growth and Emerging Issues

Rapid competition forces the team to add promotions, mobile apps, and data analysis, leading to duplicated code, tangled interfaces, oversized services, shared databases, and deployment difficulties.

3. Decision to Refactor

The team abstracts common capabilities into independent services: User, Product, Promotion, Order, and Data‑Analysis services, reducing code redundancy.

Although services are separated, they still share a single database, causing performance bottlenecks.

4. Database Split and Messaging

Each service gets its own database; a message‑queue is introduced for real‑time communication.

5. Monitoring – Detecting Fault Signs

Prometheus collects metrics from exporters (Redis, MySQL) and custom service endpoints; Grafana visualises them and sends alerts.

6. Tracing – Linking Requests

Headers carry traceId, spanId, parentId, request/response times; Zipkin (Dapper implementation) records the call tree.

7. Log Analysis

ELK stack (Elasticsearch, Logstash, Kibana) indexes logs from all services, providing a searchable “log engine”.

8. Gateway – Access Control & Service Governance

A gateway sits in front of all services, handling authentication, routing, and API documentation.

9. Service Registration & Dynamic Scaling

Services register themselves to a discovery system (e.g., Eureka, Consul, etcd); new instances are automatically discovered and load‑balanced.

10. Resilience – Circuit Breaker, Degradation, Rate Limiting

When a downstream service fails repeatedly, circuit breaking stops further calls; non‑critical features are degraded, and rate limiting protects services from overload.

11. Testing Pyramid

End‑to‑end, service‑level, and unit tests are applied; mocks replace dependent services during service tests.

12. Microservice Framework

A shared framework abstracts common code for metrics, tracing, logging, registration, and resilience, but introduces upgrade coordination challenges.

13. Service Mesh

Sidecar proxies (data plane) plus a control plane manage traffic, security, and observability without code changes; performance overhead is a trade‑off.

14. Conclusion

The microservice journey is ongoing, with future directions like Serverless, FaaS, or a return to monoliths, but the principles of modularity, observability, and resilience remain essential.