Message and Event driven systems
Message-Driven Systems
Focus: Communication and delivery mechanism
In message-driven systems, components communicate by explicitly sending messages to specific recipients. The emphasis is on addressable recipients and reliable message delivery.
Key characteristics:
Messages are directed to specific destinations (queues, services, actors)
The sender typically knows who the receiver is
Strong focus on resilience, back-pressure, and delivery guarantees
Messages contain commands or requests: "do this thing"
Often implements patterns like request-reply, pub-sub with explicit subscriptions
Example: A payment service sends a message directly to an email service saying "send payment confirmation to user@example.com". The sender knows the email service exists and addresses it directly.
Event-Driven Systems
Focus: What happened, not who should know about it
Event-driven systems center on publishing facts about things that have occurred. Publishers don't know or care who (if anyone) is listening. The emphasis is on loose coupling and reactive behavior.
Key characteristics:
Events represent immutable facts: "order was placed", "payment completed"
Publishers broadcast events without knowing subscribers
Subscribers react to events they care about
Enables emergent behavior as new subscribers can be added without changing publishers
Often implements event sourcing, CQRS, or reactive architectures
Example: A payment service publishes "PaymentCompleted" event. Multiple services (email, analytics, inventory) independently listen and react, and the payment service doesn't know they exist.
The Overlap between the two
In practice, most systems use both approaches. Event-driven systems still need reliable message transport (message-driven infrastructure). The distinction is more about design intent: are you modeling communication between known parties (message-driven) or broadcasting facts for anyone interested (event-driven)?
The Coupling Spectrum
Message-Driven (with brokers) → More Coupled
Sender often knows the specific queue/destination
Point-to-point patterns create implicit coupling: "I send orders to the order-processing-queue"
Adding new consumers may require senders to know about new queues
Request-reply patterns create temporal coupling (sender waits for response)
Event-Driven → Less Coupled
Publisher broadcasts "OrderPlaced" without knowing who listens
New subscribers can appear without any changes to publishers
No expectation of responses or specific consumers
Pure notification of facts, not commands
Important Clarifications
1. Message brokers can support both patterns: Message brokers like RabbitMQ, Kafka, or AWS SNS/SQS can implement either approach:
Message-driven use: Direct queue-to-queue communication
Event-driven use: Pub-sub topics where publishers don't know subscribers
2. The pattern matters more than the technology: You can build tightly coupled systems with event brokers, or loosely coupled systems with message queues. It's about how you use them.
3. Event-driven systems still use message brokers: Event-driven architectures typically use message brokers as the infrastructure layer. The difference is in the semantic intent:
Message: "Send this invoice to the billing service" (coupled - I know billing exists)
Event: "Invoice was generated" (decoupled - I don't care who reacts)
Visual Comparison
Message-Driven (more coupled):
Event-Driven (less coupled):
Event vs. Message
The difference lies in intent.
Feature
Message-Driven (Commands)
Event-Driven (Notifications)
Intent
"Do this." (Command)
"This happened." (Fact)
Sender
Knows exactly who should receive it.
Does not know (or care) who listens.
Coupling
Tighter. Sender expects a specific job to be done.
Loose. Sender just broadcasts info.
Example
Service A tells Service B: "Create Invoice #123"
Service A announces: "Order #123 was placed"
Last updated