80/20 Of The Week: Event-Driven Architecture (EDA)

80/20 Of The Week 🗣️ … Event-Driven Architecture (EDA)

If you ever heard stuff like Kafka or RabbitMQ… this is THAT!

Most systems you build start request-driven: User hits an endpoint → Service A calls B calls C → linear and simple

EDA flips it: Instead of “call this service”, you say “something happened” (an event) and whoever cares reacts.

Basically…

• Request-driven = calling people one by one.
• Event-driven = dropping a message in a group chat. People who care (subscribe to it) respond. People who don’t… ignore.

When do you use EDA instead of the regular system (better than the “normal” way)

• One action has many side-effects: like… OrderPlaced → payment → inventory → email → analytics → fraud checks
• Async is OK (user doesn’t need all work finished in the same request)
• Spiky traffic / bursts: broker buffers, consumers scale
• Multiple teams need to move independently: less tight coupling

When EDA is not needed

• Simple CRUD app: few side effects
• You need strong consistency NOW across services: one transaction, one truth
• Linear apps: no need to overengineer everything even if AIs tell you to some time 😭

Request-driven: Frontend → Orders API → Payment API → Inventory API → Email API → response

Event-driven: Frontend → Orders API → response ↘ publish OrderPlaced to Kafka ↘ Payment consumer ↘ Inventory consumer ↘ Analytics consumer ↘ Email consumer (for example, PaymentSucceeded)

(I had to google for this arrow emoji lol)

If one request triggers 5+ downstream actions, you already have an EDA-shaped problem 🙂