Microservice Architecture Evolution: From Monolith to Service Mesh

1: Initial Requirements The founders need a simple website and an admin backend for user registration, product display, ordering, and management of users, products, and orders.

2: Business Growth and Early Problems Rapid competition forces the team to add promotions, mobile apps, and data analysis, leading to duplicated code, tangled interfaces, oversized services, performance bottlenecks, and difficult deployments.

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

4: Database Split and Messaging Each service gets its own database; a message queue is introduced to improve real‑time performance.

5: Monitoring Prometheus scrapes metrics from RedisExporter, MySQLExporter, and custom service endpoints; Grafana visualises them and sends alerts.

6: Distributed Tracing Using Zipkin (an implementation of Google Dapper), each request carries traceId, spanId, parentId, requestTime, and responseTime in HTTP headers to reconstruct call trees.

7: Log Analysis ELK stack (Elasticsearch, Logstash, Kibana) is deployed; logs are collected by agents and indexed for fast searching.

8: API Gateway A coarse‑grained gateway handles permission checks and routing, simplifying inter‑service calls.

9: Service Registration & Discovery Services register themselves to a discovery system (e.g., Eureka, Consul) enabling dynamic scaling and client‑side load balancing.

10: Resilience Patterns Circuit breaking, service degradation, and rate limiting are applied to prevent cascading failures.

11: Testing Three testing layers are described: end‑to‑end, service‑level, and unit tests, with mock servers used for service isolation.

12: Microservice Framework A shared framework abstracts boilerplate for metrics, tracing, logging, registration, routing, circuit breaking, and rate limiting.

13: Service Mesh Sidecar proxies form a data plane; a control plane manages configuration, providing non‑intrusive traffic management.

14: Conclusion The migration is complete, but the journey continues with serverless, FaaS, and possible returns to monoliths.

End of Article