Glossary · Software Architecture
What is event-driven architecture?
Short answer
Event-driven architecture (EDA) is a design style in which services communicate by publishing events, records that something happened such as “OrderPlaced”, and other services react to them asynchronously, usually through a message broker like Kafka, RabbitMQ or SQS. Producers don’t need to know who consumes their events, which keeps systems loosely coupled and easier to extend.
How it works
When an order is placed, the order service publishes an OrderPlaced event to a broker. The email service sends a confirmation, the warehouse service reserves stock and the analytics service records a sale, each reacting on its own schedule. Adding a loyalty-points service later requires no change to the order service.
Benefits
- Loose coupling: producers and consumers evolve independently.
- Resilience: if a consumer is down, events wait in the queue instead of failing the order.
- Scalability: slow work moves out of the user’s request.
Trade-offs
- Eventual consistency: other parts of the system catch up a moment later.
- Consumers must be idempotent, because the same event can be delivered twice.
- Tracing a business flow across many asynchronous steps needs good logging and correlation IDs.
- Event formats become contracts: version them carefully.
In PHP
Laravel queues and events, Symfony Messenger and managed brokers such as Amazon SQS or RabbitMQ make event-driven designs practical without building infrastructure from scratch.
