What is Event-Driven Architecture?

Event-Driven Architecture means services communicate by emitting and listening to events. User signs up → "UserCreated" event → email service sends welcome email, analytics service tracks signup, etc. Services are decoupled—they don't call each other directly. Events go to event bus (Kafka, RabbitMQ), subscribers process them. Great for loosely-coupled systems, async workflows, and audit trails. More complex than direct calls but enables flexibility.

When Should You Use This?

Use event-driven when you have multiple services that need to react to the same action (user signup triggers 5 things), when you want services decoupled (email service doesn't know about analytics), when you need audit trails, or when operations can be async. Don't use for synchronous user-facing operations (user waits for response). Start with simple function calls, go event-driven when coupling becomes painful.

Common Mistakes to Avoid

• •Event soup—100 event types with unclear ownership
• •No schema versioning—event format changes break consumers
• •Synchronous events—events should be async, don't wait for subscribers
• •Lost events—no dead letter queue, failed events disappear
• •Event-driven everything—use for decoupling, not every function call

Real-World Examples

• •E-commerce—"OrderPlaced" event triggers inventory, shipping, email, analytics
• •Uber—Ride events (requested, accepted, completed) trigger multiple systems
• •Stripe—Payment events trigger webhooks to merchant apps
• •Netflix—Viewing events drive recommendations, analytics, billing