Event-Driven

Event-driven communication means that services communicate with each other through events. Services publish events that other services can process independently, using messaging tools such as Kafka (event streaming), RabbitMQ (message broker), or managed cloud services like AWS SNS/SQS. This approach supports independent processing, scalability, and system resilience.

✅ When is it appropriate

Event-driven communication is suitable if most of the following apply:

many services and high orchestration complexity
the number of service-to-service calls is high or traffic is bursty
the system must be highly resilient and scalable
eventual consistency is acceptable (the system may not reflect the latest state immediately, but will converge over time)
the team has experience with messaging infrastructure and event-driven architecture

In these cases, event-driven communication reduces coupling between services. Each service reacts to events independently without waiting for others, making the system more resilient and easier to scale.

❌ When is it NOT appropriate

Event-driven communication may not be ideal if:

you need immediate responses
transactional consistency is critical
the system is small or simple
orchestration is simple
low latency is critical
the team lacks experience with messaging infrastructure

Adopting event-driven communication means setting up and operating a message broker, configuring it for reliability, handling failed messages, implementing retries, monitoring queue depth and consumer lag, and debugging flows where an event may be processed seconds or minutes after it was published. For systems where a direct call would do the job, this overhead is rarely justified.

👍 Advantages

high resilience and scalability
independent processing of events
naturally fits microservices and loosely coupled systems
reduces bottlenecks and client blocking
enables horizontal scaling of services
supports deferred processing and retry mechanisms

👎 Disadvantages

more complex debugging and flow tracking
latency between the event and its processing
more challenging to guarantee transactional consistency
need for messaging infrastructure and monitoring
more complex testing and orchestration

🛠️ Typical use cases

decoupled microservices where services react to each other's state changes
microservices with a large number of calls
IoT data ingestion (e.g., sensor telemetry)
background jobs and deferred processing (e.g., sending notifications, generating reports)
systems where eventual consistency is acceptable

⚠️ Common mistakes (anti-patterns)

inappropriate combination with synchronous dependencies
not implementing retries and dead-letter queues
overloading the event bus/message queue
poor monitoring and alerting
inadequate documentation of events and their effects

Without retries and a dead-letter queue (DLQ — a separate queue where failed messages are moved so they can be inspected and reprocessed), failed events are silently dropped and the data is permanently lost. Without monitoring, an overloaded or stalled queue may go unnoticed for hours. Mixing event-driven and synchronous patterns without clear boundaries can reintroduce cascading failures, which defeats the core benefit of using event-driven communication.

💡 How to build on it wisely

Recommended approach:

Use it where independent processing is needed.
Implement retries, dead-letter queues (DLQ), and monitoring.
Document events and their effects.
Combine with synchronous approaches where appropriate.
Test latency and processing under real load.

Use event-driven communication when the publisher does not need to know the outcome before continuing. The operational cost is real, so monitoring, dead-letter queues, and event documentation are required from day one.

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.