Why events decouple services in Microservices - Design It to Understand It

Design: Event-Driven Microservices Communication

Focus on communication patterns between microservices using events. Out of scope: detailed implementation of each microservice business logic.

Functional Requirements

FR1: Services should communicate without tight dependencies

FR2: Allow independent deployment and scaling of services

FR3: Ensure services can evolve without breaking others

FR4: Support asynchronous communication for better performance

FR5: Handle failures gracefully without cascading errors

Non-Functional Requirements

NFR1: Must support at least 10,000 events per second

NFR2: Event delivery latency should be under 100ms p99

NFR3: System availability target of 99.9%

NFR4: Event ordering is not strictly required but eventual consistency is expected

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Event broker or message queue (e.g., Kafka, RabbitMQ)

Event producers and consumers

Event schema registry

Service registry or discovery

Dead letter queue for failed events

Design Patterns

Publish-Subscribe pattern

Event Sourcing

CQRS (Command Query Responsibility Segregation)

Circuit Breaker for fault tolerance

Idempotent event handling

Reference Architecture

 +----------------+       +----------------+       +----------------+
 |  Service A     |       |  Event Broker  |       |  Service B     |
 | (Producer)     | ----> | (Kafka/Rabbit) | <---- | (Consumer)     |
 +----------------+       +----------------+       +----------------+
          |                        |                        |
          |                        |                        |
          +----> Event published --+                        |
                                   +----> Event consumed --+

Components

Service A (Producer)

Any microservice framework

Generates and publishes events about business actions

Event Broker

Apache Kafka or RabbitMQ

Decouples services by handling event distribution asynchronously

Service B (Consumer)

Any microservice framework

Consumes events to react or update its own state independently

Schema Registry

Confluent Schema Registry or similar

Ensures event data format compatibility between services

Dead Letter Queue

Part of event broker

Stores events that failed processing for later inspection

Request Flow

1. Service A performs a business action and creates an event.

2. Service A publishes the event to the Event Broker asynchronously.

3. Event Broker stores and distributes the event to subscribed consumers.

4. Service B receives the event and processes it independently.

5. If Service B fails to process, the event is sent to Dead Letter Queue.

6. Services operate independently without waiting for each other.

Database Schema

Not applicable as this design focuses on event communication. However, services maintain their own databases and update state based on consumed events.

Scaling Discussion

Bottlenecks

Event Broker throughput limits when event volume grows

Consumer processing speed causing lag in event consumption

Schema evolution causing compatibility issues

Network latency affecting event delivery time

Solutions

Partition event topics and scale Event Broker horizontally

Scale consumers horizontally and implement backpressure handling

Use schema versioning and compatibility checks in Schema Registry

Deploy Event Broker and services in the same region or use CDN for faster delivery

Interview Tips

Time: Spend 10 minutes explaining the problem and why decoupling is important, 15 minutes on architecture and components, 10 minutes on scaling and failure handling, 10 minutes on Q&A.

Explain tight coupling and its drawbacks in microservices

Describe how events enable asynchronous, independent communication

Highlight the role of the event broker as a decoupling layer

Discuss failure isolation and retry mechanisms

Mention schema management to avoid breaking changes

Talk about scaling event brokers and consumers

Practice

1. Why do events help decouple microservices in a system?

easy

A. Because events force services to share the same database

B. Because events require services to be tightly connected

C. Because services communicate by sending events without waiting for direct responses

D. Because events make services dependent on each other's code

Solution

1. Step 1: Understand event communication

   Events allow services to send messages asynchronously without expecting immediate replies.

2. Step 2: Analyze coupling impact

   This asynchronous communication means services don't need to know about each other's internal details or be directly connected.

3. Final Answer:

   Because services communicate by sending events without waiting for direct responses -> Option C

4. Quick Check:

   Events enable loose coupling = B [OK]

Hint: Events mean no direct calls between services [OK]

Common Mistakes:

• Thinking events require shared databases
• Believing events increase tight connections
• Assuming events force code sharing

2. Which of the following is the correct way to describe event-driven communication between microservices?

easy

A. Service A calls Service B's API and waits for a response

B. Service A publishes an event to a message broker and continues processing

C. Service A directly updates Service B's database

D. Service A shares its memory space with Service B

Solution

1. Step 1: Identify event-driven communication

   Event-driven means a service publishes events to a broker without waiting for immediate replies.

2. Step 2: Match options to event-driven style

   Only publishing to a message broker and continuing processing fits event-driven communication.

3. Final Answer:

   Service A publishes an event to a message broker and continues processing -> Option B

4. Quick Check:

   Publish and forget = C [OK]

Hint: Event-driven means publish and continue, not wait [OK]

Common Mistakes:

• Confusing direct API calls with event publishing
• Thinking services share databases directly
• Assuming shared memory is used

3. Consider this code snippet in a microservices system using events:

eventBus.publish('OrderCreated', { orderId: 123 });
// Service B listens for 'OrderCreated' and processes the order asynchronously

What is the main benefit of this event-based approach?

medium

A. Service A directly calls Service B's function to create the order

B. Service A waits for Service B to finish processing before continuing

C. Service B must be available before Service A publishes the event

D. Service A and Service B are loosely coupled and can operate independently

Solution

1. Step 1: Analyze event publishing behavior

   Service A publishes an event and does not wait for Service B to process it immediately.

2. Step 2: Understand coupling impact

   This means Service A and Service B do not depend on each other's availability or internal logic, enabling loose coupling.

3. Final Answer:

   Service A and Service B are loosely coupled and can operate independently -> Option D

4. Quick Check:

   Asynchronous event handling = A [OK]

Hint: Events let services work independently without waiting [OK]

Common Mistakes:

• Assuming Service A waits for Service B
• Thinking Service B must be online before event publish
• Confusing direct calls with event publishing

4. A developer wrote this code snippet for event communication:

eventBus.publish('UserCreated', userData);
userService.createUser(userData);

What is the main problem with this approach regarding decoupling?

medium

A. The event is published before the user is created, causing inconsistency

B. The userService call is synchronous, blocking the event publishing

C. The eventBus and userService are tightly coupled by calling both directly

D. There is no problem; this is a fully decoupled event-driven design

Solution

1. Step 1: Check event timing relative to action

   The event 'UserCreated' is published before the actual user creation happens.

2. Step 2: Understand impact on consistency and decoupling

   This can cause other services to react to an event for a user that does not yet exist, breaking consistency and decoupling principles.

3. Final Answer:

   The event is published before the user is created, causing inconsistency -> Option A

4. Quick Check:

   Publish event after action = D [OK]

Hint: Publish events only after the action completes [OK]

Common Mistakes:

• Publishing events before the actual state change
• Assuming synchronous calls improve decoupling
• Thinking calling both is fully decoupled

5. In a large microservices system, why does using events to decouple services improve system scalability and fault tolerance?

hard

A. Because events allow services to process messages independently and retry on failure

B. Because events force all services to run on the same server

C. Because events require services to be tightly synchronized

D. Because events eliminate the need for any service monitoring

Solution

1. Step 1: Understand event-driven processing benefits

   Events let services handle messages independently, so they can scale by adding more instances and retry failed processing without blocking others.

2. Step 2: Analyze impact on fault tolerance and scalability

   This independence isolates failures and allows the system to continue working smoothly, improving overall reliability and scalability.

3. Final Answer:

   Because events allow services to process messages independently and retry on failure -> Option A

4. Quick Check:

   Independent processing and retries = A [OK]

Hint: Events enable independent retries and scaling per service [OK]

Common Mistakes:

• Thinking events force services to share servers
• Assuming tight synchronization improves scalability
• Believing events remove need for monitoring