Why event-driven

Event-driven architecture is not “use Kafka everywhere.” It is a deliberate choice: publish what happened, let others react on their own schedule, and accept eventual consistency where that trade is worth it.

When it pays off

Events help when:

• multiple consumers need the same fact (notifications, projections, analytics, downstream workflows)
• producers and consumers must deploy independently
• work can happen after the user-facing response (enrichment, reconciliation, email)
• you need to absorb spikes without failing the write path
• you may need to replay history into a new consumer

In payments and banking this is common: capture a payment, then fan out to ledger projections, risk signals, notifications, and reconciliation — without holding the customer request open for every downstream system.

What you are trading away

You give up simple request/response mental models:

• no immediate confirmation that every consumer succeeded
• ordering and duplicates become first-class design problems
• debugging spans producers, brokers, and many consumers
• schema and ownership disputes show up as silent breakage

If one service always needs an answer before it can continue, keep that path synchronous. Events are for facts that already happened, not for “please do this and tell me now.”

Smell tests

Prefer events when the answer to “must the caller wait?” is no.

Prefer sync (or a workflow engine) when the user or business step cannot proceed without a result.

Reject “event-driven” that is really RPC over topics: request topics, reply topics, and chatty back-and-forth with no clear ownership of state. That is coupling with worse tooling.

Start from ownership

Events do not fix bad boundaries. If two services still share a database or still need lockstep releases, Kafka will only move the pain. Own the fact in one place, publish it clearly, and let consumers own their reactions.