> For the complete documentation index, see [llms.txt](https://stephen-tsoi.gitbook.io/stephen-tsoi-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://stephen-tsoi.gitbook.io/stephen-tsoi-docs/event-driven-architecture/when-you-start-eda-the-events-never-stop.md).

# 🚀 When You Start EDA, the Events Never Stop

An architectural analysis of exponential event volume growth in mature EDA ecosystems, balancing high-throughput business value with critical resource monitoring parameters.

After an organization begins its Event-Driven Architecture (EDA) journey and migrates applications from traditional point-to-point integrations to a messaging backbone, one interesting trend often emerges:

#### Event volume grows rapidly. <a href="#ember64" id="ember64"></a>

What starts as dozens of transactions per second (TPS) can quickly become hundreds, thousands, millions, and eventually billions of events. In some organizations, this transformation can happen within just a few years.

#### Once you start EDA, the events never stop. <a href="#ember66" id="ember66"></a>

Is that a good thing or a bad thing?

In most cases, it is actually a positive sign.

It usually indicates that your EDA adoption is moving in the right direction and that more business processes are becoming event driven.

#### What Is Really Happening? <a href="#ember70" id="ember70"></a>

Higher TPS is often a sign of deeper EDA adoption. In mature EDA environments, event volume often grows faster than application count because each business event can create value for many consumers simultaneously.

### From Request-Driven Architecture to Event-Driven Architecture <a href="#ember72" id="ember72"></a>

On Day 1, many organizations simply replace point-to-point communication with a messaging platform. While the transport mechanism changes, the message design often remains the same.

Large messages containing hundreds or even thousands of records are still exchanged between systems.

As EDA matures, applications begin to publish events at a more granular level. Instead of sending one large batch message, systems emit individual business events whenever a change occurs.

This naturally increases TPS, not because the system is becoming inefficient, but because business activities are now represented as discrete events.

### Less Bandwidth Waste and Better Resource Utilization <a href="#ember77" id="ember77"></a>

Smaller events are distributed throughout the day rather than being concentrated in large batch files.

This approach provides several advantages:

* More even network utilization
* Reduced processing spikes
* Better parallelism across consumers
* Improved scalability

Backend services are also evolving. Instead of repeatedly querying databases and returning large snapshots of data, they publish incremental changes (deltas) as events occur.

As a result, computing resources are used more efficiently throughout the entire integration landscape.

### Lower Latency and Higher Throughput <a href="#ember83" id="ember83"></a>

An event represents something that has just happened.

Instead of waiting for scheduled jobs, batch windows, or query requests, information can flow directly from the producer to interested consumers in near real time.

Benefits include:

* ✅ Lower end-to-end latency
* ✅ Faster business reaction time
* ✅ Reduced dependency on polling mechanisms
* ✅ Higher overall throughput

The result is a more responsive and scalable digital ecosystem.

### Greater Reusability <a href="#ember89" id="ember89"></a>

As TPS increases, it is common to observe outbound event rates significantly exceeding inbound event rates. This typically indicates that events are being fanned out to multiple consumers, enabling independent and parallel processing for different business purposes. The same business event can be reused across multiple domains and functions, such as auditing, analytics, monitoring, reporting, and AI-driven insights, maximizing the value of each published event.

#### However, event growth alone should not be considered a success metric. The objective of EDA is to represent meaningful business activities as events. Poor governance, redundant event publication, and inconsistent schemas can increase event volume without creating business value. <a href="#ember91" id="ember91"></a>

### What Should Architects Monitor? <a href="#ember92" id="ember92"></a>

A growing event rate is generally a good sign, but it also introduces new operational considerations.

As event volumes continue to rise, architects and platform teams should closely monitor:

#### 1. Ingress Rate <a href="#ember95" id="ember95"></a>

* Number of incoming messages/events
* Total inbound data volume

#### 2. Egress Rate <a href="#ember97" id="ember97"></a>

* Number of outgoing messages/events
* Total outbound data volume

#### 3. Concurrent Connections <a href="#ember99" id="ember99"></a>

* Producer connections
* Consumer connections
* Platform connection limits

#### 4. Platform Capacity <a href="#ember101" id="ember101"></a>

* Throughput headroom
* Storage utilization
* Network bandwidth
* Replication traffic

### Final Thoughts <a href="#ember103" id="ember103"></a>

Event growth is one of the natural outcomes of a successful EDA transformation. The question is not whether the number of events will increase. The question is whether your platform, governance model, and operating practices are ready to support that growth on a scale.

#### Once you start EDA, the events never stop. The organizations that succeed are those that turn that endless stream of events into business value. 🚀 <a href="#ember105" id="ember105"></a>

<figure><img src="https://2617374589-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FcQN1DZY6gJZPxlsQf9Re%2Fuploads%2FI6hya6v2eR6s1UUx0bDd%2Fimage.png?alt=media&amp;token=83a1a736-28cf-41c4-8ff3-6427120aeeab" alt=""><figcaption></figcaption></figure>

## 🚀 Let's Connect Beyond GitBook!

If you found this article helpful, you can find more of my technical insights, daily discussions, and deep dives across these platforms:

* **Read more of my work:** Check out my articles on [dev.to](https://dev.to/stephen_tsoi_5b2c4055f3a9) and [Hashnode](https://stephentsoi.hashnode.dev/).
* **Join the daily conversation:** Connect with me directly on [LinkedIn](https://www.linkedin.com/in/stephen-tsoi-16309730/).

***

#### 📬 Stay Ahead of the Curve

Enjoyed this piece? I break down complex technical topics into bite-sized, actionable insights every week.

👉 **Subscribe to my** [**LinkedIn Newsletter**](https://www.linkedin.com/build-relation/newsletter-follow?entityUrn=7487299517642612736) to never miss an update and get the latest articles delivered straight to your feed!


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://stephen-tsoi.gitbook.io/stephen-tsoi-docs/event-driven-architecture/when-you-start-eda-the-events-never-stop.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.