Event-Driven Architecture: Building Loosely Coupled Systems

Event-driven architecture decouples services by communicating through events. When a user places an order, the Order service emits "OrderPlaced", and Inventory, Payment, and Notification services react independently. LinkedIn processes 7 trillion events per day.

Core Concepts

Event: A fact that something happened ("OrderPlaced", "UserRegistered")
Producer: Service that emits events
Consumer: Service that reacts to events
Broker: Middleware that routes events (RabbitMQ, Kafka, SQS)

Laravel Events Implementation

class OrderPlaced
{
    public function __construct(
        public readonly Order $order,
        public readonly User $user,
    ) {}
}

class SendOrderConfirmation
{
    public function handle(OrderPlaced $event): void
    {
        Mail::to($event->user)->queue(new OrderConfirmationMail($event->order));
    }
}

class UpdateInventory implements ShouldQueue
{
    public $tries = 3;
    public $backoff = [10, 60, 300];

    public function handle(OrderPlaced $event): void
    {
        foreach ($event->order->items as $item) {
            Product::where('id', $item->product_id)
                ->decrement('stock', $item->quantity);
        }
    }

    public function failed(OrderPlaced $event, Throwable $e): void
    {
        Log::critical('Inventory update failed', [
            'order_id' => $event->order->id,
        ]);
    }
}

// Dispatch
OrderPlaced::dispatch($order, $user);

CQRS Pattern

Command Side (Write):
  → Validates → Updates database → Emits events

Query Side (Read):
  → Reads from optimized, denormalized read models
  → Updated by event listeners

Benefits

• Loose coupling — services don't know about each other
• Scalability — consumers scale independently
• Resilience — failed consumers retry without blocking
• Audit trail — events provide a natural activity log