Event-driven vs request-driven in Microservices - Quick Revision & Key Differences

Recall & Review

beginner

What is a request-driven architecture in microservices?

Request-driven architecture means services communicate by sending direct requests and waiting for responses, like making a phone call to ask for information.

beginner

Define event-driven architecture in simple terms.

Event-driven architecture means services react to events or messages sent by others without waiting, like receiving a notification and acting on it when it arrives.

intermediate

What is a key benefit of event-driven architecture over request-driven?

Event-driven architecture allows services to work independently and handle tasks asynchronously, improving scalability and fault tolerance.

intermediate

What is a common challenge when using request-driven communication?

Request-driven communication can cause tight coupling and delays because services wait for responses, which may slow down the system if one service is slow or down.

beginner

Give an example scenario where event-driven architecture is preferred.

When many services need to react to changes independently, like updating inventory, sending notifications, and logging after a purchase, event-driven is preferred.

Which architecture involves services sending direct requests and waiting for responses?

A Event-driven

B Request-driven

C Batch processing

D Peer-to-peer

Request-driven architecture uses direct calls where one service waits for another's response.

In event-driven architecture, how do services communicate?

A By reacting to events asynchronously

B By polling each other continuously

C By sharing a common database

D By sending synchronous requests

Services react to events asynchronously without waiting for immediate responses.

What is a main advantage of event-driven systems?

A Better scalability and fault tolerance

B Tight coupling between services

C Synchronous communication

D Simpler debugging

Event-driven systems allow services to scale independently and handle failures gracefully.

Which problem is common in request-driven microservices?

A Services never communicate

B Services are loosely coupled

C Services wait and block on responses

D Services use events to communicate

Request-driven services often wait for responses, causing delays or blocking.

When is event-driven architecture most useful?

A When services never communicate

B When immediate response is required

C When services share a single database

D When services must act independently on changes

Event-driven is best when services react independently to events without waiting.

Explain the differences between event-driven and request-driven architectures in microservices.

Think about how services talk and wait for each other.

Describe a real-world example where event-driven architecture improves system design over request-driven.

Consider systems with many independent reactions to one action.

Practice

1. Which statement best describes an event-driven microservice architecture?

easy

A. Services communicate by sending messages without waiting for immediate responses.

B. Services make direct calls and wait for responses before continuing.

C. Services share a common database to exchange data synchronously.

D. Services use batch processing to handle requests at fixed intervals.

Solution

1. Step 1: Understand event-driven communication

   Event-driven systems use messages or events to notify other services asynchronously, without waiting for a reply.

2. Step 2: Compare with request-driven communication

   Request-driven systems make direct calls and wait for responses, which is synchronous communication.

3. Final Answer:

   Services communicate by sending messages without waiting for immediate responses. -> Option A

4. Quick Check:

   Event-driven = asynchronous messaging [OK]

Hint: Event-driven means no waiting for replies, just messages [OK]

Common Mistakes:

• Confusing event-driven with synchronous calls
• Thinking event-driven requires shared databases
• Assuming event-driven always uses batch processing

2. Which of the following is the correct way to describe a request-driven call in microservices?

easy

A. Service A sends an event and continues without waiting.

B. Service A writes data to a shared database for Service B to read later.

C. Service A processes requests in batches asynchronously.

D. Service A calls Service B and waits for a response before proceeding.

Solution

1. Step 1: Identify request-driven behavior

   Request-driven means a service calls another and waits for the response before moving on.

2. Step 2: Eliminate other options

   Options A and D describe asynchronous or event-driven behavior; Service A writes data to a shared database for Service B to read later. describes shared database, not direct calls.

3. Final Answer:

   Service A calls Service B and waits for a response before proceeding. -> Option D

4. Quick Check:

   Request-driven = synchronous call and wait [OK]

Hint: Request-driven means wait for reply before continuing [OK]

Common Mistakes:

• Mixing event-driven with request-driven
• Thinking shared database equals request-driven
• Confusing batch processing with request-driven calls

3. Consider this scenario: Service A sends an event to a message broker, and Service B listens and processes it asynchronously. What is the main advantage of this design?

medium

A. Service B can process events at its own pace without blocking Service A.

B. Service B must respond immediately to Service A's request.

C. Service A and B share the same database for faster communication.

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

Solution

1. Step 1: Analyze asynchronous event processing

   Service A sends an event and does not wait; Service B processes independently.

2. Step 2: Identify the advantage

   This allows Service B to handle events at its own speed without blocking Service A, improving scalability and decoupling.

3. Final Answer:

   Service B can process events at its own pace without blocking Service A. -> Option A

4. Quick Check:

   Asynchronous event-driven = decoupled processing [OK]

Hint: Async events let receivers work independently [OK]

Common Mistakes:

• Assuming sender waits for receiver
• Confusing shared database with event broker
• Expecting immediate response in event-driven

4. You have a microservice that calls another service synchronously but experiences high latency and failures. Which change can improve reliability using event-driven design?

medium

A. Increase the timeout for synchronous calls to wait longer.

B. Replace synchronous calls with asynchronous events and retries.

C. Use a shared database for both services to read and write data.

D. Batch multiple synchronous calls into one to reduce overhead.

Solution

1. Step 1: Identify problem with synchronous calls

   High latency and failures occur because the caller waits and depends on the callee's immediate response.

2. Step 2: Apply event-driven solution

   Switching to asynchronous events decouples services, allowing retries and better fault tolerance without blocking.

3. Final Answer:

   Replace synchronous calls with asynchronous events and retries. -> Option B

4. Quick Check:

   Event-driven improves reliability by decoupling [OK]

Hint: Async events with retries reduce blocking and failures [OK]

Common Mistakes:

• Just increasing timeout doesn't fix failures
• Shared database doesn't solve latency issues
• Batching synchronous calls still blocks

5. A company wants to design a microservices system for online orders. They need fast user feedback and flexible processing of orders. Which architecture best fits their needs?

hard

A. Use only request-driven calls for all services to ensure immediate responses.

B. Use only event-driven design for all services to maximize decoupling.

C. Use request-driven calls for order validation and event-driven for inventory updates.

D. Use batch processing to handle orders every hour for efficiency.

Solution

1. Step 1: Analyze requirements for fast feedback and flexibility

   Fast user feedback needs synchronous validation; flexible processing benefits from asynchronous events.

2. Step 2: Combine architectures appropriately

   Request-driven calls provide immediate validation; event-driven updates allow inventory to process independently and scale.

3. Final Answer:

   Use request-driven calls for order validation and event-driven for inventory updates. -> Option C

4. Quick Check:

   Mix sync for speed + async for flexibility [OK]

Hint: Mix sync for fast feedback, async for flexible tasks [OK]

Common Mistakes:

• Using only event-driven delays user feedback
• Using only request-driven limits scalability
• Batch processing is too slow for online orders