0
0
Microservicessystem_design~12 mins

Why events decouple services in Microservices - Architecture Impact

Choose your learning style9 modes available
LearnWhyDeepArchPracticeChallengeDesignRecallScale
System Overview - Why events decouple services

This system shows how using events helps separate services so they don't depend on each other directly. It allows services to work independently and communicate through messages, making the system more flexible and easier to maintain.

Architecture Diagram
User
  |
  v
Load Balancer
  |
  v
API Gateway
  |
  v
+----------------+       +----------------+
| Service A      |       | Service B      |
| (Event Sender) |       | (Event Listener)|
+----------------+       +----------------+
         |                        |
         |                        |
         v                        v
   +-----------------------------+
   |       Event Broker          |
   |  (Message Queue / Topic)    |
   +-----------------------------+
         |                        |
         |                        |
         v                        v
   +----------------+       +----------------+
   | Database A     |       | Database B     |
   +----------------+       +----------------+
Components
User
user
Initiates requests to the system
Load Balancer
load_balancer
Distributes incoming requests evenly to API Gateway instances
API Gateway
api_gateway
Receives user requests and routes them to appropriate services
Service A (Event Sender)
service
Processes requests and publishes events to the event broker
Service B (Event Listener)
service
Listens for events from the event broker and acts accordingly
Event Broker (Message Queue / Topic)
message_queue
Decouples services by holding and forwarding events asynchronously
Database A
database
Stores data for Service A
Database B
database
Stores data for Service B
Request Flow - 10 Hops
User → Load Balancer
Load Balancer → API Gateway
API Gateway → Service A (Event Sender)
Service A (Event Sender) → Database A
Service A (Event Sender) → Event Broker (Message Queue / Topic)
Service A (Event Sender) → API Gateway
API Gateway → Load Balancer
Load Balancer → User
Event Broker (Message Queue / Topic) → Service B (Event Listener)
Service B (Event Listener) → Database B
Failure Scenario
Component Fails:Event Broker (Message Queue / Topic)
Impact:Service B will not receive events and cannot update its data, causing delays or stale data. Service A can still process requests and write to its database but the system loses decoupling benefits.
Mitigation:Use a highly available event broker with replication and failover. Implement retry mechanisms and dead-letter queues to handle undelivered events.
Architecture Quiz - 3 Questions
Test your understanding
Why does Service B not call Service A directly in this architecture?
ATo avoid tight coupling and allow independent scaling
BBecause Service A is offline
CTo reduce database load
DBecause Service B cannot handle HTTP requests
Design Principle
Using events to decouple services allows each service to work independently and communicate asynchronously. This reduces direct dependencies, improves scalability, and increases system resilience.