Event-driven architecture (EDA) is a design pattern where the flow of the program is determined by events;significant changes in state that other parts of the system care about. When applied thoughtfully, EDA creates systems that are loosely coupled, scalable, and easy to extend. Here's how to get started.
What Is Event-Driven Architecture?
In traditional request-response architecture, component A calls component B directly. A knows about B and depends on it.
In event-driven architecture, component A publishes an event. Components B, C, and D might all listen for that event and react to it. A doesn't know or care who's listening.
This inversion changes everything. New functionality can be added by creating new listeners without modifying existing code. Components can be developed and deployed independently. Systems become more resilient;if one listener fails, others continue working.
Events vs. Commands vs. Queries
These three concepts are often confused but serve different purposes.
Events
Events describe something that happened. They're named in past tense: OrderPlaced, UserRegistered, PaymentFailed. Events are facts;once published, they can't be changed.
Events have multiple consumers. Many different parts of your system might care that an order was placed: inventory, shipping, analytics, notifications.
Commands
Commands describe something you want to happen. They're named imperatively: PlaceOrder, RegisterUser, ProcessPayment. Commands target a specific handler.
Commands have exactly one handler. "Place an order" goes to the order service. It doesn't make sense for multiple components to independently try to place the same order.
Queries
Queries ask for information without changing state: GetOrderDetails, ListUserOrders. They're requests for data.
The key insight: commands and events are asymmetric. Commands are one-to-one (caller to handler). Events are one-to-many (publisher to many subscribers).
Benefits of Event-Driven Architecture
Loose Coupling
Components interact through events rather than direct calls. When a user registers, the registration component publishes UserRegistered. Email, analytics, and onboarding components listen and react.
If you later add a loyalty program, you just add a new listener. The registration component doesn't change at all.
Scalability
Event-driven systems scale naturally. When load increases, add more listeners. Events can be processed in parallel across multiple workers.
Message queues provide buffer between publishers and consumers. A spike in orders doesn't overwhelm downstream systems;events queue up and are processed at sustainable rates.
Audit Trails
Events create a natural audit log. If you record every event, you have a complete history of everything that happened in your system.
This goes beyond debugging. Event logs support compliance, analytics, and even system reconstruction (more on that with event sourcing).
Resilience
When component A directly calls component B, A fails if B is down. With events, A publishes and moves on. If B is temporarily unavailable, events queue up and are processed when B recovers.
Implementation Patterns
Simple Event Publishing
At its simplest, event-driven means firing events when significant things happen:
class OrderService
{
public function placeOrder(array $items, User $user): Order
{
$order = Order::create([
'user_id' => $user->id,
'items' => $items,
]);
event(new OrderPlaced($order));
return $order;
}
}
Event Sourcing
Event sourcing takes events further: instead of storing current state, you store the sequence of events that led to current state.
Traditional: Save order.status = 'shipped'
Event sourced: Store events OrderPlaced, PaymentReceived, OrderShipped. Current status is derived by replaying events.
Benefits:
- Complete audit history automatically
- Can reconstruct state at any point in time
- Events are your single source of truth
Tradeoffs:
- More complex queries (can't just SELECT current state)
- Requires careful event schema design
- Steeper learning curve
Event sourcing isn't for every system. Consider it when audit trails are critical or when you need to analyze how state changed over time.
CQRS (Command Query Responsibility Segregation)
CQRS separates read and write models. Commands modify a write model optimized for consistency. Queries read from a read model optimized for fast retrieval.
When state changes, events propagate changes to read models. You might store writes in a normalized relational database while maintaining denormalized views in Elasticsearch for fast searching.
This adds complexity but enables powerful scaling patterns. Write-heavy and read-heavy components scale independently.
Message Queues
For production event-driven systems, you need a message broker. Options include:
- Redis: Simple, fast, good for moderate volumes
- RabbitMQ: Feature-rich, supports complex routing
- Amazon SQS: Managed service, scales automatically
- Apache Kafka: High throughput, event log retention
Laravel's queue system abstracts these differences. Configure your driver and use the same API regardless of backend.
Laravel's Event System
Laravel provides robust event support out of the box.
Defining Events
class OrderPlaced
{
use Dispatchable, SerializesModels;
public function __construct(
public Order $order
) {}
}
Creating Listeners
class SendOrderConfirmation
{
public function handle(OrderPlaced $event): void
{
Mail::to($event->order->user)
->send(new OrderConfirmationMail($event->order));
}
}
Registering in EventServiceProvider
protected $listen = [
OrderPlaced::class => [
SendOrderConfirmation::class,
UpdateInventory::class,
NotifySalesTeam::class,
],
];
Queued Listeners
For non-blocking event processing, queue your listeners:
class UpdateInventory implements ShouldQueue
{
public function handle(OrderPlaced $event): void
{
// This runs asynchronously
}
}
The event publisher continues immediately while listeners process in the background.
Event Broadcasting
Laravel can broadcast events to WebSocket connections for real-time updates:
class OrderStatusUpdated implements ShouldBroadcast
{
public function broadcastOn(): Channel
{
return new PrivateChannel('orders.'.$this->order->id);
}
}
Combine with Laravel Echo on the frontend for live updates without polling.
When Event-Driven Architecture Makes Sense
EDA adds complexity. That complexity is justified when:
- Multiple components need to react to the same changes
- Components are developed by different teams
- System load varies significantly (queues smooth spikes)
- Audit trails or replay capability are important
- You need real-time updates across clients
- Services will be deployed independently
EDA is overkill when:
- A simple request-response flow suffices
- The application is monolithic with a small team
- Events would have only one listener
- Development speed is more important than architectural purity
Getting Started
You don't need to convert your entire application to event-driven. Start small:
- Identify a notification that's currently inline;email on order, Slack on error
- Convert it to an event and listener
- Queue the listener
- Add additional listeners as needs arise
This gives you the pattern without wholesale architectural change. As you gain experience, you'll recognize more opportunities for events.
Common Pitfalls
Event Explosion
Don't create events for everything. Events should represent meaningful domain occurrences. UserClickedButton is probably too granular. UserCompletedOnboarding captures significant state change.
Temporal Coupling
Just because events are asynchronous doesn't mean order doesn't matter. If listener B depends on listener A completing first, you need to handle that;either through saga patterns or by combining into a single listener.
Lost Events
Without proper infrastructure, events can be lost. Use persistent queues. Implement retry logic. Monitor for stuck or failed jobs. Dead-letter queues capture events that consistently fail.
Conclusion
Event-driven architecture shifts how you think about system design. Instead of asking "who do I need to call?", you ask "what just happened that others might care about?"
This shift enables loose coupling, scalability, and extensibility. New functionality becomes additive;create a new listener rather than modifying existing code.
Start with Laravel's event system. It's simple enough for basic use cases yet powerful enough to grow with your needs. As your system evolves, you can add message brokers, event sourcing, or CQRS as requirements demand.
The goal isn't event-driven purity. It's using events where they provide clear benefits while keeping direct calls where they make sense. Like all architectural patterns, EDA is a tool;powerful in the right context, overkill in others.