Event-driven Architecture (EDA)

Software architecture involves many trade-offs. A poor choice can lead to rework and delays, so it is important to know the available options and understand when each one makes sense.

In this article, we will talk about Event-driven Architecture (EDA), a style whose main characteristic is communication between services through events.

What is EDA?

Event-driven Architecture promotes the production, detection, consumption of and reaction to events. An event can be any fact relevant to the system: a state change, a user action, an error or a received message.

Events are asynchronous messages generated by a producer and consumed by one or more consumers. The producer does not need to know the consumers, and the consumers do not need to know the producers. This makes it possible to build systems that are more decoupled, scalable and flexible.

In this article’s example, we will simulate the following scenario:

Hands-on example

The system is made up of four services.

ecommerce-frontend

• Frontend of an e-commerce store that lets you add products to the cart.
• Uses React to build the user interface.

stock-service

• Manages product stock.
• Uses PHP to communicate with RabbitMQ.

A simplified example of publishing a stock event in PHP:

$message = new AMQPMessage(json_encode([
    'order_id' => 1,
    'status' => 'updated',
]));

$channel->basic_publish($message, '', 'stock_updated');

The code above is just a teaching example, not working or production-safe code.

payment-service

• Processes order payments.
• Uses Python to communicate with RabbitMQ.

def process_payment(order):
    print(f"Processing payment for order: {order['order_id']}")
    return True

rabbitmq

• Message broker that enables communication between the services.
• Receives published events and routes them to interested consumers.

The full code is available in the project repository.

Communication flow

1. The user opens the e-commerce frontend and adds a product to the cart.
2. The frontend sends a request to the stock service to check out.
3. The stock service checks availability and publishes an event to RabbitMQ.
4. The payment service consumes the event and processes the payment.
5. The payment service publishes an event with the result of the processing.

Trade-offs

This flow is a simple example of how EDA can decouple services and enable asynchronous communication without producers and consumers having to know each other. Each service is responsible for one task and can be replaced or updated with less impact on the others.

On the other hand, event-driven architecture increases operational complexity. You have to deal with ordering, delivery, idempotency, traceability and debugging of distributed problems.

So before adopting EDA, consider whether the benefits outweigh that complexity for your project.

Conclusion

Event-driven Architecture is a powerful alternative for building decoupled, flexible and resilient systems. There is no perfect architecture: the best choice depends on the project’s requirements, constraints and operational maturity.

The full code is available on GitHub.