# When EDA Fits and When It Does Not — Event-Driven Architecture & CQRS

Source: https://www.skillbyai.com/en/event-driven-architecture/f-when

> Decide whether an event-driven design is worth its cost for a given problem.

## Benefits with a bill attached

EDA shines when **many independent consumers** care about the same business facts, when work can happen **later** (emails, analytics, search indexing, recommendations), when you need to **absorb bursts** with a buffer, when teams must evolve services independently, and when you need an **audit trail** of what happened. It is a poor fit when the user needs an **immediate, consistent answer** ("is this seat still available?"), when the flow is a simple sequence inside one team's service, or when the team lacks the operational maturity to run brokers, monitor consumer lag and debug asynchronous flows. Most real systems mix styles: synchronous APIs for queries and user-facing decisions that need an answer now, events for propagating facts afterwards.

## A quick decision checklist

Score a proposed flow before reaching for a broker.

```text
Use events when most answers are YES:
  [ ] Do several services need to react to this fact?
  [ ] Can the reaction happen seconds later without hurting the user?
  [ ] Should the publisher stay unaware of who reacts?
  [ ] Do we need to replay or audit what happened?
  [ ] Must we absorb traffic spikes without dropping work?

Prefer a direct call when:
  [ ] The caller needs the result to continue (validation, price, availability)
  [ ] Strong consistency is required right now
  [ ] Only one consumer exists and is owned by the same team
```

## Post versus phone call

You post a parcel when it can arrive tomorrow; you phone when you need an answer before you hang up. Using the post for urgent questions, or calling for every parcel, both make life harder.

**Quiz:** A checkout must confirm card authorisation before showing "Order confirmed". What fits that step best?

- [ ] Publishing an event and immediately showing success
- [ ] A nightly batch job
- [x] A synchronous call (or a flow that waits for the result) before confirming
- [ ] An analytics event

*Answer:* A synchronous call (or a flow that waits for the result) before confirming. The user needs the authorisation result to proceed, so that decision should not be fire-and-forget.