DEV Community

Cover image for Event driven systems: Webhook vs EventBridge-style API vs Event Sourcing vs CQRS
Shiv Rai (S_RAI)
Shiv Rai (S_RAI)

Posted on AI-assisted

Event driven systems: Webhook vs EventBridge-style API vs Event Sourcing vs CQRS

#webdev #tutorial #systemdesign #api

What are Event-Driven Systems?

Instead of requesting information or invoking functionality directly, event-driven systems communicate by publishing facts about things that have already occurred.

Examples include:

  • Order placed
  • Payment completed
  • User registered
  • Invoice generated
  • Shipment delivered

The event itself does not tell consumers what to do. It simply communicates that something happened. Consumers decide independently whether and how to react.

Modern systems are often composed of many independent services, applications, and teams. Direct communication creates dependencies between those systems. Events reduce coupling by allowing producers and consumers to evolve independently.

Common use cases include:

  • System integration
  • Business process automation
  • Distributed architectures
  • Audit and compliance systems
  • Event-driven workflows
  • Data synchronization
  • Reactive applications

Messaging systems and event-driven systems are often used together, but they are not the same thing. Messaging systems provide transport infrastructure, while event-driven systems define how systems communicate and coordinate through events.

This article covers: Webhook, EventBridge-style API, Event Sourcing, CQRS

Event-Driven Integration vs Event-Driven Architecture

This category contains two related but distinct concepts.

Event-Driven Integration focuses on moving events between systems.

Examples include:

  • Webhooks
  • EventBridge-style APIs

The goal is integration and event distribution.

Event-Driven Architecture (EDA) focuses on how applications are internally designed around events.

Examples include:

  • Event Sourcing
  • CQRS

The goal is modeling, storing, and processing business behavior through events.

A useful rule of thumb:

  • Integration technologies help systems communicate.
  • Architectural patterns help systems organize and process information internally.

The Purpose

Technology Type Primary Purpose
Webhooks Event-Driven Integration Mechanism Notify external systems when events occur
EventBridge-style APIs Event Routing & Integration Platform Distribute events across multiple systems and consumers
Event Sourcing Architectural Pattern Store application state as a sequence of events
CQRS Architectural Pattern Separate command and query responsibilities

These technologies are frequently combined:

  • A webhook may notify an external system about an event generated internally.
  • EventBridge-style platforms may distribute events originating from Event Sourcing systems.
  • Event Sourcing and CQRS are often used together to build event-driven applications.
  • CQRS systems frequently consume events transported through messaging infrastructure.

Decision Tree

Integration and internal architecture are independent decisions — a system may need one, the other, or both at the same time.

How should events be integrated externally?

  • Webhooks are usually the simplest choice for notifying external systems.
  • EventBridge-style APIs become valuable when events must be routed to multiple consumers or across many systems. 
flowchart TD

A1[How should events be<br/>integrated externally?] --> B1{Need simple notifications<br/>to external systems?}

B1 -->|Yes| WEBHOOKS[Webhooks]
B1 -->|No — multiple consumers<br/>or systems involved| EVENTBRIDGE[EventBridge-style APIs]

How should events be handled internally?

  • Event Sourcing is most useful when event history itself becomes a business requirement.
  • CQRS is most useful when read and write workloads have significantly different requirements.
  • Event Sourcing + CQRS often appears in complex event-driven systems where auditability, scalability, and specialized read models are important. 
flowchart TD

A2[How should events be<br/>handled internally?] --> D{Need a complete historical<br/>record of state changes?}

D -->|No| E{Need independent read and<br/>write models or optimized queries?}

E -->|No| F[Traditional Architecture]
E -->|Yes| CQRSONLY[CQRS Alone]

D -->|Yes| G{Need independent read and<br/>write models or optimized queries?}

G -->|No| ES[Event Sourcing Alone]
G -->|Yes| ESCQRS[Event Sourcing + CQRS]

A system might, for example, use Webhooks for external notifications while internally combining Event Sourcing with CQRS — the two trees are meant to be walked separately, not as a single either/or choice.

Comparison

Aspect Webhooks EventBridge-style APIs Event Sourcing CQRS
Category Event-Driven Integration Event Routing & Integration Architectural Pattern Architectural Pattern
Abstraction Level Integration Mechanism Event Distribution Platform State Management Pattern Read/Write Separation Pattern
Primary Purpose Notify external systems Route and distribute events Store state changes as events Separate commands and queries
Stores Events? No Sometimes platform-dependent Yes No
Event Routing? Basic Core capability No No
External Integration? Yes Yes Indirectly Indirectly
Internal Architecture? No No Yes Yes
Historical Replay? Limited Platform-dependent Core capability No — only available when paired with Event Sourcing
Complexity Low Medium High Medium to High
Typical Use Cases Third-party integrations, notifications Event distribution, cloud integrations Auditability, financial systems, workflow tracking High-scale systems, specialized read models
Strengths Simple, widely supported, easy adoption Centralized event routing and fan-out Complete event history and replayability Flexible scaling and optimized read/write paths
Weaknesses Limited routing and reliability guarantees Additional infrastructure and operational complexity Significant modeling and operational complexity Additional architectural complexity

Webhooks

Webhooks emerged in the mid-2000s. Webhooks were never a formal protocol. They evolved as a practical integration pattern. Early APIs polled data:

Your App
    |
GET /status
    |
No Change

Wait

GET /status
    |
No Change

Wait

GET /status
Enter fullscreen mode Exit fullscreen mode

As SaaS products grew, polling became inefficient.

Companies needed a better way to notify customers about events.

Webhooks answer: How can one system notify another system immediately when something happens?

Instead of:

Consumer
   |
"Anything new?"
Enter fullscreen mode Exit fullscreen mode

repeatedly,

the producer says:

"I'll call you when
something happens."
Enter fullscreen mode Exit fullscreen mode

This transformed API integrations.

Webhooks think in callbacks

Core assumption: The consumer provides a URL and waits for events.

Instead of:

Client ---> Server
Enter fullscreen mode Exit fullscreen mode

you get:

Client gives URL

Server ---> Client
Enter fullscreen mode Exit fullscreen mode

The direction reverses.

Example

Suppose a payment succeeds.

Provider sends:

POST /webhook

Content-Type: application/json
Enter fullscreen mode Exit fullscreen mode

Body:

{
  "event": "payment.succeeded",
  "amount": 100
}
Enter fullscreen mode Exit fullscreen mode

Your application receives:

app.post("/webhook", (req, res) => {
  console.log(req.body);

  res.sendStatus(200);
});
Enter fullscreen mode Exit fullscreen mode

Output:

{
  "event": "payment.succeeded",
  "amount": 100
}
Enter fullscreen mode Exit fullscreen mode

Pros and Cons

Pros Cons
Extremely simple Reliability must be handled carefully
Real-time notifications Consumer must expose a public endpoint
Eliminates polling Duplicate deliveries can occur
Uses standard HTTP Debugging failures can be difficult
Easy cross-company integrations No built-in replay mechanism
Widely supported by SaaS platforms Not ideal for high-volume streams
Low infrastructure requirements Limited delivery guarantees

EventBridge-Style APIs

Cloud-native event buses emerged in the late 2010s as cloud providers looked to formalize the producer-announces, consumers-react pattern as a managed service. AWS EventBridge launched in 2019, followed by comparable services like Azure Event Grid and Google Eventarc. These platforms popularized event-driven integration at scale, giving teams a managed event bus instead of building and operating one themselves.

As systems became more distributed, organizations ended up with architectures like:

User Service
     |
     +--> Email Service
     |
     +--> Analytics
     |
     +--> Billing
     |
     +--> CRM
Enter fullscreen mode Exit fullscreen mode

Every new consumer required another integration.

Over time:

One Event
      |
Ten Integrations
      |
Twenty Integrations
Enter fullscreen mode Exit fullscreen mode

became difficult to manage. EventBridge-style systems answer: How can services publish events once and allow anyone to react without creating direct integrations?

Instead of:

Producer
   |
Many Consumers
Enter fullscreen mode Exit fullscreen mode

they introduce:

Producer
   |
Event Bus
   |
Many Consumers
Enter fullscreen mode Exit fullscreen mode

The producer knows only about the bus.

EventBridge thinks in business events

Core assumption: Systems should announce facts, not call other systems.

Instead of:

Order Service
   |
Call Email Service
Enter fullscreen mode Exit fullscreen mode

you get:

Order Service
   |
OrderCreated Event
   |
Event Bus
   |
Email Service Reacts
Enter fullscreen mode Exit fullscreen mode

Example

Publish Event

{
  "source": "orders",
  "type": "OrderCreated",
  "data": {
    "orderId": 123
  }
}
Enter fullscreen mode Exit fullscreen mode

Event Rule

{
  "type": "OrderCreated"
}
Enter fullscreen mode Exit fullscreen mode

Target

Email Service
Enter fullscreen mode Exit fullscreen mode

When an order is created:

Order Service
      |
OrderCreated
      |
Event Bus
      |
Email Service
Enter fullscreen mode Exit fullscreen mode

The email service automatically receives the event.

Pros and Cons

Pros Cons
Loose coupling between services Harder debugging and tracing
Easy to add new consumers Eventual consistency
Excellent for event-driven systems Event schema versioning challenges
Centralized routing rules Hidden dependencies can emerge
Strong cloud integration Not suitable for request/response
Scales organizationally Added architectural complexity
Enables automation workflows Less predictable execution paths

Event Sourcing

Event Sourcing became a mainstream architectural pattern around 2008–2012.

Most applications store current state and lose history.

Example:

500 -> 700 -> 400 -> 900
Enter fullscreen mode Exit fullscreen mode

After updates, only 900 remains.

Organizations wanted auditability, traceability, and rebuildability without relying on fragile audit tables. Event Sourcing answers: What if we stored every change instead of only the latest state?

Instead of:

Current Balance = 900
Enter fullscreen mode Exit fullscreen mode

store:

AccountOpened
MoneyDeposited(200)
MoneyWithdrawn(300)
MoneyDeposited(500)
Enter fullscreen mode Exit fullscreen mode

The current state can always be reconstructed.

Event Sourcing thinks in facts, not state

Core assumption: The sequence of events matters more than the current state.

Instead of:

User
------
Name: Alice
Plan: Pro
Enter fullscreen mode Exit fullscreen mode

store:

UserRegistered
PlanUpgraded
Enter fullscreen mode Exit fullscreen mode

Current state becomes a derived value.

Example

Traditional CRUD

UPDATE accounts
SET balance = 500
WHERE id = 1;
Enter fullscreen mode Exit fullscreen mode

Result:

Balance = 500
Enter fullscreen mode Exit fullscreen mode

Previous history may be lost.

Event Sourcing

Append event:

{
  "type": "MoneyDeposited",
  "amount": 100
}
Enter fullscreen mode Exit fullscreen mode

Then:

{
  "type": "MoneyWithdrawn",
  "amount": 50
}
Enter fullscreen mode Exit fullscreen mode

Current balance is computed from events:

+100
-50
----
50
Enter fullscreen mode Exit fullscreen mode

Pros and Cons

Pros Cons
Complete audit trail Significant complexity
Event replay capability Event schema evolution challenges
Time-travel debugging Eventual consistency
Strong compliance support Steep learning curve
Natural fit for event-driven systems Storage growth over time
Easier historical analysis More infrastructure and tooling
Rebuild projections anytime Overkill for simple CRUD systems

CQRS

CQRS (Command Query Responsibility Segregation) was introduced by Greg Young around 2010.

Most applications use a single model for both:

Reading Data
Writing Data
Enter fullscreen mode Exit fullscreen mode

Example:

User Table
      |
 Read Users
 Update Users
 Delete Users
 Create Users
Enter fullscreen mode Exit fullscreen mode

This works well initially.

But large systems often discover that read traffic doesn't match write traffic.

For example, Instagram might see millions of reads but only thousands of writes per second.

CQRS answers: What if reads and writes were treated as separate concerns?

Instead of one model for everything, CQRS introduces:

Write Model
     |
Read Model
Enter fullscreen mode Exit fullscreen mode

Each side can be optimized independently.

CQRS thinks in commands and queries

Core assumption: The way you update data is often different from the way you retrieve it.

Example: Updating an order:

Validate
Authorize
Apply Business Rules
Enter fullscreen mode Exit fullscreen mode

Viewing an order:

Fetch
Format
Display
Enter fullscreen mode Exit fullscreen mode

These concerns do not necessarily belong in the same model.

Example

Traditional CRUD

Orders Table
Enter fullscreen mode Exit fullscreen mode

Used for:

SELECT *
FROM orders
Enter fullscreen mode Exit fullscreen mode

and:

UPDATE orders
SET status='shipped'
Enter fullscreen mode Exit fullscreen mode

Same model.

CQRS

Write side:

ShipOrder Command
Enter fullscreen mode Exit fullscreen mode

Read side:

OrderDetails Query
Enter fullscreen mode Exit fullscreen mode

Two separate paths.

Command
   |
Write Model
Enter fullscreen mode Exit fullscreen mode 
Query
   |
Read Model
Enter fullscreen mode Exit fullscreen mode

Pros and Cons

Pros Cons
Independent read/write optimization Significantly more complexity
Better scalability Eventual consistency issues
Cleaner domain logic More infrastructure required
Flexible read models Harder debugging
Excellent for read-heavy systems More moving parts to maintain
Natural fit for event-driven architectures Steeper learning curve
Can improve performance dramatically Overkill for many applications

Key Takeaways

Use Webhooks when...

  • External systems need notifications
  • Integration requirements are relatively simple
  • You want the lowest operational overhead

Use EventBridge-style APIs when...

  • Events must be distributed to multiple consumers
  • Systems are highly decoupled
  • Centralized event routing is valuable

Use Event Sourcing when...

  • Event history is a business requirement
  • Auditability and replayability matter
  • State changes must be preserved permanently

Use CQRS when...

  • Read and write workloads have different requirements
  • Query performance becomes a concern
  • Independent scaling of commands and queries is beneficial

Use Event Sourcing + CQRS when...

  • Building complex event-driven systems
  • Historical event storage and specialized read models are both required
  • Additional architectural complexity is justified by business needs

Top comments (0)