Like many teams we didn’t choose event-driven architecture in the first place.

At first, the application was relatively simple. A user performed an action, the backend processed it, updated the database, and returned a response.

But as the product evolved new requirements showed up!

A single action didn’t just affect one part of the system.

Creating or updating data could trigger:

Price recalculations
Cache invalidations
Real-time frontend updates
Audit logging
Notifications
Reporting updates

Initially, these responsibilities were handled directly inside service methods.
A simplified example looked something like this:

def update_price(data):

 price = calculate_price(data)

 save(price)

 update_cache(price)

 create_audit_log(price)

 realtime_update(price)

 update_reports(price)

At first this approach seemed to work.

But over time problems grew.

The Cost of Coupling
Every new requirement meant modifying existing code.

Even a simple business change may require changing multiple services.

The result was:

Larger service functions and methods
More dependencies that became impossible to maintain over time
More testing complexity that eventually became unmanageable
Higher risk during deployment
Unexpected behavior during edge cases

The Real-Time Challenge
The biggest challenge appeared when we introduced more real-time functionality.

Frontend clients needed immediate updates whenever important data changed.

Users needed immediate updates whenever important data or data related to them changed.

A Different Perspective
So instead of asking which services need to be called, we start to ask what happened?

And rather than directly invoking downstream processes, we introduced events.

Services no longer needed to know who was interested in those events.

They simply published them.

Consumers could subscribe and react independently.

What Changed
Instead of this:

Service A

├─ Service B

├─ Service C

└─ Service D

We moved toward:

Service A

│

▼

Event Bus

│

├─ Consumer B

├─ Consumer C

└─ Consumer D

The producer became responsible only for publishing an event.

Consumers became responsible for their own behavior.

This significantly reduced coupling between components.

Benefits We Observed
Easier Feature Development
Adding new features often means a new event consumer rather than modifying existing business logic.

Better Separation of Concerns
Services focused on their responsibilities instead of coordinating multiple downstream processes.

Improved Real-Time Updates
Frontend updates became event-driven rather than tightly integrated into backend workflows.

What We Learned
Moving to an event-driven architecture did not eliminate complexity.

It changed where the complexity lived.

We had to think about:

Event contracts
Idempotency
Ordering
Delivery guarantees

However, these challenges were easier to manage rather than dependencies we had before.

The architecture change gave us a system that could evolve without requiring every component to know about every other one.

And as the application grew, that flexibility became one of the most valuable decisions we made.

Have you made the move to event-driven architecture? What were your challenges and how to solve them?