Event-Driven Architecture in Laravel Without Overengineering It

'Event-driven architecture' conjures Kafka clusters and dedicated infrastructure teams, and plenty of Laravel apps reach for exactly that before they've outgrown what Laravel's own event system, dispatched onto queued listeners, already handles cleanly.

• Domain events (OrderPlaced, UserRegistered) dispatched from models or actions decouple side effects from the core write path.
• Queued listeners give you async processing and retry semantics without introducing a separate broker.
• Only reach for a real message broker (SQS, RabbitMQ) when multiple independent services — not just modules in one app — need to consume the same event.
• Event sourcing as a persistence strategy is a much bigger commitment than 'using events' — don't conflate the two.

The Laravel apps I've seen overengineer this jumped straight to a message broker for decoupling that queued listeners inside the same monolith already provided, paying operational cost for a scaling problem they didn't actually have yet.

You don't need Kafka to decouple a write from its side effects. You need an event and a queue, which Laravel already gives you.