FoodExpress is an online food delivery platform that connects customers with restaurants. Initially, it was developed using a monolithic architecture, where all functionalities—such as user authentication, restaurant management, order processing, payments, delivery tracking, and customer reviews—were combined in a single application.
As FoodExpress expanded to new cities, it faced serious challenges:
- Scaling Issues - A surge in orders during peak meal times slowed down the entire application.
- Deployment Bottlenecks - A minor change in the restaurant menu system required redeploying the entire application.
- Team Dependencies - Different teams working on unrelated functionalities had to coordinate their code changes.
- Performance Degradation - Certain features (like reviews and recommendations) were overwhelming the database, impacting critical services like payments and order processing.
To solve these issues, FoodExpress decided to migrate to a microservices architecture.
When FoodExpress initially transitioned to microservices, they did not properly define service boundaries, leading to issues with tight coupling and low cohesion:
-
Tight Coupling Between Order and Payment Services
- The Order Service directly called the Payment Service synchronously. If the Payment Service was slow or unavailable, the Order Service would also fail.
- This created a single point of failure and impacted order processing speed.
-
Low Cohesion in the Delivery Service
- The Delivery Service handled delivery tracking, driver assignments, and customer feedback all within the same service.
- This led to unnecessary complexity, making it hard to maintain and deploy changes.
-
Database Sharing Between Services
- The Order Service and Customer Service were both accessing the same user database.
- If the schema of the Customer Service changed, the Order Service also needed to be updated, causing deployment delays and breaking dependencies.
To fix these issues, FoodExpress restructured its microservices using Domain-Driven Design (DDD) principles.
- Asynchronous Communication with Event-Driven Architecture
- The Order Service no longer called the Payment Service synchronously.
- Instead, it published an event ("Order Created") to a message queue (Kafka/RabbitMQ).
- The Payment Service listened for this event and processed payments asynchronously.
- If the Payment Service failed, the order was retried or flagged for manual intervention, avoiding complete system failure.
-
Splitting the Delivery Service into Independent Cohesive Microservices
- The Delivery Tracking Service handled real-time tracking and customer notifications.
- The Driver Assignment Service managed driver availability and automatic assignments.
- The Feedback Service collected customer ratings separately.
-
This separation made the system easier to maintain, test, and scale.
- Each microservice had its own database instead of sharing a common database.
- A Customer Profile Service was introduced to act as a data provider for both Order and Customer Services via APIs instead of direct database access.
- This ensured service autonomy and allowed for independent scaling.
| Service | Responsibility | Improvements |
|---|---|---|
| Auth Service | Manages user authentication | Decoupled from other services, reducing dependencies. |
| Order Service | Handles order placements and updates | Communicates with Payment Service via event-driven messaging. |
| Payment Service | Processes payments asynchronously | Loosely coupled with Order Service, improving resilience. |
| Restaurant Service | Manages restaurant menus and availability | Independent from other services, preventing bottlenecks. |
| Delivery Tracking Service | Tracks real-time delivery updates | Decoupled from driver assignment logic. |
| Driver Assignment Service | Assigns drivers based on availability | Focuses only on assignment logic, improving cohesion. |
| Feedback Service | Manages customer ratings and reviews | No longer coupled with delivery tracking. |
🚀 Increased System Resilience - If one service failed, it no longer affected others.
🚀 Faster Deployments - Teams could update services independently.
🚀 Improved Scalability - Order, Payment, and Delivery Services scaled separately based on demand.
🚀 Better Maintainability - Developers focused on smaller, well-defined services.
🚀 Higher System Availability - Asynchronous messaging prevented failures from cascading.
- Loose Coupling is critical to prevent failures in one service from affecting others. Use asynchronous messaging, well-defined APIs, and database independence.
- High Cohesion ensures that services handle a single responsibility, making them easier to develop, scale, and maintain.
- Avoid Database Sharing - Instead, use API-based communication between services.
- Monitor Service Dependencies - Ensure that services do not become overly dependent on each other, leading to "Distributed Monolith" issues.
- What risks arise when microservices are tightly coupled?
- How does event-driven architecture help reduce coupling in microservices?
- What challenges can arise when breaking down services for high cohesion?
- What trade-offs exist between synchronous and asynchronous service communication?
- How can database coupling lead to poor microservice design?
- What techniques can be used to identify whether a microservice has low cohesion?
- How would you decide whether to merge or split a microservice?
- What monitoring tools can help track inter-service dependencies?
- Is it possible to make microservices too loosely coupled? What are the risks?
- How can microservices communicate while maintaining autonomy and independence?