Event-Driven Architecture (EDA) — architectural style where services communicate via publish/subscribe events rather than direct API calls. Producer emits event → message broker (Kafka, RabbitMQ, AWS SNS) delivers → consumers react. Loose coupling: producer doesn't know consumers. Use cases: order processing, notifications, analytics pipelines. Contrast: synchronous REST/gRPC.
Below: details, example, related terms, FAQ.
Free online tool — HTTP header checker: instant results, no signup.
// Producer
producer.send('order.placed', {
orderId: 'ord-123',
customerId: 'c-456',
total: 99.99
});
// Consumer (OrderService reads)
consumer.on('order.placed', async (event) => {
await sendEmail(event.customerId);
await updateInventory(event.items);
});Event-Driven Architecture (EDA) is a software design pattern that focuses on the production, detection, consumption, and reaction to events. It decouples components, allowing systems to be more scalable and responsive. EDA is commonly implemented using message brokers like Apache Kafka or AWS EventBridge, facilitating real-time data processing and integration across distributed systems.
Event-Driven Architecture is built upon several fundamental concepts that contribute to its effectiveness in modern application development:
In EDA, the decoupling of producers and consumers allows for greater flexibility and scalability. As systems grow, new event consumers can be added without altering the existing architecture, promoting a modular approach to software design.
To illustrate the implementation of Event-Driven Architecture, let's consider a practical example using Apache Kafka, a widely-used event streaming platform. In this scenario, we will build a simple order processing system that captures user orders as events.
First, you need to install Apache Kafka on your system. You can download it from the official Kafka website and follow the installation instructions. Once installed, start the Kafka server using the following commands:
bin/zookeeper-server-start.sh config/zookeeper.propertiesbin/kafka-server-start.sh config/server.propertiesNext, create a topic called orders to which order events will be published:
bin/kafka-topics.sh --create --topic orders --bootstrap-server localhost:9092 --partitions 3 --replication-factor 1Now, you can create a simple producer to send order events to the Kafka topic. Below is a sample Python script using the kafka-python library:
from kafka import KafkaProducer
import json
producer = KafkaProducer(bootstrap_servers='localhost:9092',
value_serializer=lambda v: json.dumps(v).encode('utf-8'))
order_event = {'order_id': 1234, 'user_id': 'user_1', 'amount': 250.00}
producer.send('orders', value=order_event)
producer.flush()Finally, create a consumer that listens for events from the orders topic. Below is an example consumer script:
from kafka import KafkaConsumer
import json
consumer = KafkaConsumer('orders',
bootstrap_servers='localhost:9092',
auto_offset_reset='earliest',
group_id='order_group',
value_deserializer=lambda x: json.loads(x.decode('utf-8')))
for message in consumer:
print(f'Received order: {message.value}')
With this setup, whenever a new order event is produced, it will be consumed by the consumer, demonstrating the core principles of Event-Driven Architecture. This approach allows for real-time processing of orders, enabling quick responses to user actions and system changes.
EDA — async, decoupled. RR — sync, tight coupling. EDA scales better, RR easier to debug. Most systems — hybrid (EDA cross-service, RR inside service).
Kafka — high-throughput streams, long retention, replay. RabbitMQ — queues with routing rules. Kafka for analytics/logs, RabbitMQ for task queues.
UI shows optimistic updates + reconciles later. APIs return pending state. For banking — use saga pattern with compensating actions.
Free plan — 10 monitors, checks every 5 min, no card required. Upgrade for 1-minute interval and multi-region monitoring.