Event-Driven vs. Request-Response

This page will help you decide what communication style to use between services or components.

Answer a few questions → Get a clear recommendation.

Options you can choose from:

Event-Driven

Services communicate using events that are published and subscribed to by other services. Typically implemented using a message bus (e.g., Kafka, RabbitMQ, AWS SNS/SQS).

Request-Response

The client sends a request and waits for an immediate response. Typically uses synchronous protocols such as REST or gRPC.

Answer a few simple questions below. 👇

Based on your answers, you will receive specific recommendations that you can click on to view in detail.

Decision questions

Answer honestly according to the current needs of the system.

1. How critical are immediate responses?

2. How often are new services added or changed?

3. How complex are the interactions between parts of your system?

4. How important is it that the system keeps working even if one part fails?

5. How much data is sent and how often do services communicate?

6. What is the team's experience with messaging and async systems?

Result

Based on your answers, see the recommended solution below. 👇

Each option has its own page where you will find:

  • when it is appropriate
  • when it is not
  • typical usage
  • most common mistakes
Event-Driven
When to use it, common mistakes & best practices
→
Request-Response
When to use it, common mistakes & best practices
→

Important note

⚠️ Both approaches are valid and often combined in modern systems. The choice depends on latency, number of services, system dynamics, and team experience.

Consider the result as a recommendation, not a dogma.

Feedback & Sharing

Give us your thoughts on this page, or share it with others who may find it useful.

Share with your network:

Feedback

Found this helpful? Let me know what you think or suggest improvements 👉 Contact me.