From Monolith to Microservices: Transforming an Online Supermarket

Introduction

The article introduces microservice architecture and its key components, explaining why organizations move from monolithic applications to microservices and what benefits they aim to achieve.

Initial Requirements and Monolithic Design

A small online supermarket is built by two founders. The initial functional checklist includes:

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

Admin backend: user management, product management, order management

The first deployment is a single monolithic application hosted on a cloud VM, illustrated by the following diagram:

Growth, New Demands, and Emerging Problems

Rapid business growth forces the team to add marketing campaigns, a mobile app, and data‑driven personalization. Development pressure leads to ad‑hoc extensions: promotion management and data analysis are merged into the admin backend, while a new mobile app is built separately. This results in:

Duplicated business logic across website and mobile app

Inconsistent data sharing (some via shared DB, some via API calls)

Blurred service boundaries and tangled responsibilities

Performance bottlenecks in the admin backend

Shared database schema that cannot be refactored

Complex deployment and testing processes

Team friction over ownership of common functionality

Despite the quick delivery, the short‑term focus compromises long‑term architecture.

First Refactor: Service Extraction

The team abstracts common capabilities into independent services:

User Service

Product Service

Promotion Service

Order Service

Data‑Analysis Service

Each application now calls these services for data, reducing redundant code. The architecture diagram after this step is shown below:

Second Refactor: Database Isolation and Messaging

Because a shared database still creates a single point of failure and performance limits, each service receives its own database. A message‑queue layer is added for real‑time communication. The updated architecture diagram is:

Now services can choose heterogeneous storage: the analytics service uses a data warehouse, while product and promotion services add caching layers.

Operational Challenges of Microservices

Even with a clean service split, new challenges appear:

Fault isolation becomes harder because a failure in one service can cascade (snow‑ball effect).

System stability decreases as the number of services grows.

Deployment, management, and scaling workload increase dramatically.

Coordinated development is required to keep interfaces compatible.

Testing becomes more complex due to inter‑service dependencies.

Monitoring

To detect early signs of trouble, each component exposes a uniform /metrics endpoint. Exporters (e.g., RedisExporter, MySQLExporter) provide these metrics, which Prometheus scrapes. Grafana visualises the data and sends alerts when thresholds are crossed.

Tracing (Link Tracking)

Each request carries four HTTP headers: traceId, spanId, parentId, and timestamps. The team adopts Zipkin (an open‑source Dapper implementation) and injects these headers via an HTTP interceptor. The trace data is visualised as a tree, showing the call chain from the front‑end to downstream services.

Logging

Large‑scale systems require a searchable log store. The ELK stack (Elasticsearch, Logstash, Kibana) is used: services write logs to files, lightweight agents ship them to Logstash, which indexes them in Elasticsearch. Kibana provides the UI for queries.

Gateway and Service Governance

An API gateway sits between callers and services, handling authentication, routing, and rate limiting. The team chooses a coarse‑grained approach: one gateway for the whole system, with intra‑service calls bypassing it.

Service Registration & Discovery

To avoid manual load‑balancer updates, services automatically register themselves with a discovery system (e.g., Consul, Eureka, etc.). New instances only need to be deployed; the discovery service updates client side load‑balancing tables in real time.

Resilience Patterns

Circuit Breaker : after repeated failures, calls are short‑circuited until the downstream service recovers.

Service Degradation : non‑critical features are disabled when their dependent service fails.

Rate Limiting : excess requests are dropped or throttled, optionally per caller.

Testing Strategy

Three testing layers are recommended:

End‑to‑end tests covering user‑visible flows (expensive but highest confidence).

Service tests for each API contract.

Unit tests for individual code units (fastest, lowest confidence).

Mock servers help isolate services during service‑level testing.

Microservice Framework vs Service Mesh

The team builds a lightweight framework that bundles metric, tracing, logging, and registration code for all services. However, framework upgrades require coordinated releases. A service mesh (e.g., sidecar proxies) offers similar capabilities without code changes, at the cost of additional latency.

Conclusion

Microservice architecture is not an end point; future directions include serverless/FaaS and, paradoxically, a renewed interest in monoliths. Successful adoption requires careful planning, robust observability, automated discovery, resilience patterns, and disciplined testing.