Event-Driven Architecture

Most applications start the same way. A user clicks a button. The frontend sends a request to the backend. The backend calls the database, calls three other services, updates state, sends an email, logs analytics, and returns a response. All synchronous. All in one request handler. All tightly coupled.

It works at first. Then the system grows. The email service takes 2 seconds. The analytics service is down. The recommendation engine needs to react to every purchase but nobody told the order service team. Every new feature requires modifying the order handler, adding another synchronous call, making the response slower, and increasing the blast radius of any failure.

Event-driven architecture (EDA) inverts this model. Instead of the order service calling every downstream service directly, it publishes a single event: "OrderPlaced." Any service that cares subscribes to that event and reacts independently. The order service doesn't know or care who's listening. Adding a new service that reacts to orders requires zero changes to the order service.

This isn't just a messaging pattern, it's an architectural philosophy. Systems communicate through events instead of direct calls. State changes are announced, not commanded. Services are autonomous reactors, not orchestrated puppets.

Netflix processes over 8 million events per second through their event-driven platform. LinkedIn handles 7 trillion messages per day through Kafka. Uber's entire ride lifecycle, request, match, pickup, trip, payment, is orchestrated through events. This architecture is how you build systems that scale to millions of users without every team stepping on each other's toes.

Event-driven architecture distinguishes three types of messages, and confusing them is the #1 mistake teams make:

Events describe something that already happened. Past tense. Immutable. The publisher doesn't expect anything from subscribers.

OrderPlaced { orderId: "123", userId: "456", amount: 99.99 }
UserSignedUp { userId: "789", email: "roni@example.com" }
PaymentFailed { orderId: "123", reason: "insufficient_funds" }

Commands are instructions to do something. Imperative. Directed at a specific handler. The sender expects the command to be executed.

CreateOrder { userId: "456", items: [...] }
SendEmail { to: "roni@example.com", template: "welcome" }
ChargePayment { orderId: "123", amount: 99.99 }

Queries are read requests. They don't change state.

GetOrderById { orderId: "123" }
ListUserOrders { userId: "456" }

The critical distinction: Events are notifications ("this happened"). Commands are instructions ("do this"). In EDA, services communicate primarily through events, not commands. The order service doesn't send a "SendConfirmationEmail" command to the email service. It publishes an "OrderPlaced" event. The email service subscribes to that event and decides to send an email. The order service has zero knowledge of email.

This distinction matters because events are infinitely extensible. Ten services can subscribe to "OrderPlaced" without the order service knowing. Commands create point-to-point coupling, the sender must know the receiver.