Event-driven systems are everywhere. Inspired by Martin Fowler’s insights and a thought-provoking LinkedIn post by Dragan Stepanović, let’s break down event-driven systems in plain, practical terms.
I can’t think of any other way to implement event driven architecture without some sort of messaging. Could you give examples of how this architecture could be implemented without those tools?
As noted in the article, EDA is more about the design principles and patterns than the tools used to implement them. Here's how EDA can work without relying on traditional messaging systems like Kafka, RabbitMQ, or AWS SQS:
1. Direct HTTP/Webhook-Based Event Notification or Callbacks
Example: Imagine a microservice architecture where each service can expose HTTP endpoints for receiving events.
2. Database as the Communication Medium
Example: Use a shared database table to store events. Each service can write events to the table, and subscribers periodically poll the table for new events.
3. Event Streaming via Server-Sent Events or WebSockets
Example: A server pushes events to clients (subscribed services) in real time using SSE or WebSockets.
4. Filesystem as an Event Bus
Example: For simpler systems, you could write event data as files in a shared directory or cloud storage (like Amazon S3).
5. HTTP Pull/Long Polling
Example: In systems where services can’t handle real-time pushes, the subscribers can periodically pull for updates from the publishing service.
The Key Takeaway
The core of event-driven architecture is decoupling—systems communicate through events rather than direct, synchronous calls. While message brokers often make EDA easier to scale and manage, they are not strictly necessary for implementing EDA. Depending on your system's requirements (scalability, real-time processing, fault tolerance), one of the above approaches could be a lightweight alternative.
I can’t think of any other way to implement event driven architecture without some sort of messaging. Could you give examples of how this architecture could be implemented without those tools?
Thank you for the question Phillip!
As noted in the article, EDA is more about the design principles and patterns than the tools used to implement them. Here's how EDA can work without relying on traditional messaging systems like Kafka, RabbitMQ, or AWS SQS:
1. Direct HTTP/Webhook-Based Event Notification or Callbacks
Example: Imagine a microservice architecture where each service can expose HTTP endpoints for receiving events.
2. Database as the Communication Medium
Example: Use a shared database table to store events. Each service can write events to the table, and subscribers periodically poll the table for new events.
3. Event Streaming via Server-Sent Events or WebSockets
Example: A server pushes events to clients (subscribed services) in real time using SSE or WebSockets.
4. Filesystem as an Event Bus
Example: For simpler systems, you could write event data as files in a shared directory or cloud storage (like Amazon S3).
5. HTTP Pull/Long Polling
Example: In systems where services can’t handle real-time pushes, the subscribers can periodically pull for updates from the publishing service.
The Key Takeaway
The core of event-driven architecture is decoupling—systems communicate through events rather than direct, synchronous calls. While message brokers often make EDA easier to scale and manage, they are not strictly necessary for implementing EDA. Depending on your system's requirements (scalability, real-time processing, fault tolerance), one of the above approaches could be a lightweight alternative.