Request-response vs event-driven in Microservices - Practice Questions

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding communication styles in microservices

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

A Both request-response and event-driven are synchronous communication styles.

B Request-response is asynchronous and does not wait for a reply; event-driven is synchronous and waits for a reply.

C Both request-response and event-driven require the sender to wait for a reply before continuing.

D Request-response is synchronous and waits for a reply; event-driven is asynchronous and does not wait for a reply.

💡 Hint

Think about whether the sender waits for a response or not.

Request-response communication is synchronous, meaning the sender waits for the receiver to respond before continuing. Event-driven communication is asynchronous; the sender emits an event and continues without waiting for a reply.

❓ Architecture

intermediate

Choosing communication style for a user login service

You are designing a user login microservice that must verify credentials and immediately respond with success or failure. Which communication style is most appropriate?

A Request-response, because the client needs an immediate answer to proceed.

B Event-driven, because it allows the login service to process requests asynchronously.

C Event-driven, because it reduces the need for direct communication between services.

D Request-response, because it queues login requests for later processing.

💡 Hint

Consider if the client needs an immediate answer or can wait.

Login requires immediate feedback to the user, so request-response is suitable because it provides synchronous communication with immediate results.

❓ scaling

advanced

Scaling microservices with event-driven architecture

Which advantage does event-driven architecture provide when scaling microservices compared to request-response?

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

B It forces services to wait for responses, reducing load on downstream services.

C It requires synchronous calls, which simplifies scaling by limiting concurrency.

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

💡 Hint

Think about how asynchronous processing affects load handling.

Event-driven architecture decouples services, allowing them to handle events asynchronously and independently, which improves scalability and fault tolerance.

❓ tradeoff

advanced

Tradeoffs between request-response and event-driven communication

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

A Request-response communication is always slower than event-driven communication.

B Event-driven communication guarantees immediate consistency and simpler error handling.

C Event-driven communication can increase complexity due to eventual consistency and harder debugging.

D Request-response communication eliminates the need for message brokers.

💡 Hint

Consider the challenges of asynchronous systems.

Event-driven systems often face challenges like eventual consistency, increased complexity, and difficulty tracing errors compared to synchronous request-response systems.

❓ estimation

expert

Estimating message volume in event-driven microservices

A microservice emits an event for every user action. If there are 10,000 users each performing 5 actions per minute, how many events per second does the system generate?

A Approximately 500 events per second

B Approximately 833 events per second

C Approximately 3,000 events per second

D Approximately 50,000 events per second

💡 Hint

Calculate total events per minute, then convert to per second.

Total events per minute = 10,000 users * 5 actions = 50,000 events/minute. Divide by 60 seconds to get approximately 833 events/second.