Event-driven vs request-driven in Microservices - Practice Questions

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding communication style in microservices

Which statement best describes the main difference between event-driven and request-driven communication in microservices?

A Event-driven uses asynchronous messages to notify changes, while request-driven uses synchronous calls expecting immediate responses.

B Event-driven requires direct calls between services, while request-driven uses message queues.

C Request-driven communication is always asynchronous, while event-driven is always synchronous.

D Event-driven communication does not support decoupling, while request-driven does.

💡 Hint

Think about how services interact and wait for responses.

Event-driven communication is asynchronous and decouples services by sending events without waiting for immediate replies. Request-driven communication is synchronous, where one service calls another and waits for a response.

❓ Architecture

intermediate

Choosing communication style for a payment system

You are designing a payment processing microservice that must confirm payment success before updating the order status. Which communication style is most suitable?

A Event-driven, because it allows the payment service to notify order service asynchronously after processing.

B Event-driven, because it guarantees immediate response from payment service.

C Request-driven, because the order service needs immediate confirmation to update status synchronously.

D Request-driven, because it avoids any communication between services.

💡 Hint

Consider if the order service needs to wait for payment confirmation before proceeding.

Since the order service must update status only after payment confirmation, synchronous request-driven communication is suitable to get immediate response. Event-driven is asynchronous and may delay confirmation.

❓ scaling

advanced

Scaling microservices with event-driven architecture

Which advantage does event-driven architecture provide when scaling microservices under high load?

A It eliminates the need for message brokers, reducing infrastructure complexity.

B It forces all services to wait for each other, reducing concurrency issues.

C It requires synchronous calls that simplify load balancing.

D It allows services to process events independently and at their own pace, improving scalability and fault tolerance.

💡 Hint

Think about how asynchronous processing affects service independence and load handling.

Event-driven architecture decouples services so they can consume and process events independently, which helps handle high load by scaling services separately and improving fault tolerance.

❓ tradeoff

advanced

Tradeoffs between event-driven and request-driven communication

What is a key tradeoff when choosing event-driven communication over request-driven in microservices?

A Event-driven improves decoupling but can make debugging and tracing harder due to asynchronous flows.

B Event-driven guarantees immediate responses but increases coupling between services.

C Request-driven communication eliminates the need for service discovery.

D Request-driven communication is always faster and more scalable than event-driven.

💡 Hint

Consider how asynchronous communication affects system observability.

Event-driven communication decouples services but introduces complexity in tracing and debugging because events flow asynchronously and may be processed later, making it harder to track the full request path.

❓ estimation

expert

Estimating message volume in event-driven microservices

A microservice emits an event for every user action. If the system has 10,000 users each performing 5 actions per minute, estimate the number of events generated per hour.

A 30,000 events per hour

B 3,000,000 events per hour

C 300,000 events per hour

D 600,000 events per hour

💡 Hint

Calculate total actions per minute and multiply by 60 minutes.

10,000 users * 5 actions/minute = 50,000 events per minute. Over 60 minutes: 50,000 * 60 = 3,000,000 events per hour.

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