Beyond APIs: Why real-time enterprises need events too

What if one of the most connected enterprises in the world could still be completely unaware that something important just happened?

It sounds contradictory. After all, if systems are connected, APIs are available and information can move between applications on demand, it would seem reasonable to assume that the enterprise should know what is happening across the business. Yet there is an important difference between having access to information and knowing when something has changed, and that difference becomes increasingly significant as organisations move towards real-time operations.

APIs have transformed enterprise technology by making data and business capabilities accessible across applications, platforms and organisational boundaries. They allow systems to request information, invoke capabilities and retrieve the latest state of almost anything the business chooses to expose. But within that interaction sits an assumption that is easy to overlook: the consumer needs to know there is a reason to make the request in the first place.

This creates an interesting situation. Something meaningful can change somewhere in the business and the information about that change can already exist, while every system that needs it may have both the technical ability and permission to access it. Yet if those consumers have no reason to ask at that particular moment, the change can remain invisible to them until something triggers the next request.

In other words, an enterprise can be highly connected, with information available across its architecture and still lack immediate awareness of what is actually changing within the business.

That gap matters because becoming real-time is not simply about making information faster to retrieve. It is about reducing the distance between something happening and the organisation being able to recognise it, understand its significance and respond while that information still has value.

This is where events introduce a different dimension to enterprise architecture. Rather than relying entirely on consumers to discover change by requesting the latest information, events allow meaningful business activity to become visible as it happens. Systems, processes and services can then decide independently whether that change matters to them and what, if anything, should happen next.

This does not diminish the role of APIs, nor does it suggest that events should replace them. The more interesting architectural opportunity lies in understanding how APIs and events complement one another: one providing controlled access to information and capabilities, the other making meaningful business change visible when it occurs.

So the question is not whether enterprises should move beyond APIs by leaving them behind. It is:

Why APIs alone do not create a real-time enterprise

The limitation is not that APIs fail to provide access to information; they are exceptionally effective at doing exactly that. The limitation appears when the enterprise needs to recognise a change that no consumer yet knows it should be looking for.

Understanding why requires looking at the interaction model behind most APIs.

The request-response model depends on someone asking

Most APIs operate through a straightforward interaction: a consumer sends a request and a provider returns a response.

If a travel application wants the latest information about a particular journey, it can request it: GET /journeys/123/status

The API might respond: ON_TIME

That interaction works efficiently because the consumer knows exactly what information it needs, where to find it and when to ask for it.

Now imagine that ten minutes later the journey is cancelled.

The operational system knows that the state has changed and the latest information is available for any authorised consumer to retrieve. The API, however, does not independently tell every interested application that the cancellation has occurred. The travel application can discover the new status whenever it asks again, but until something causes that request to happen, it may continue operating with its previous understanding of reality.

This is where the limitation becomes visible. The information is available, but discovering that it has changed remains the responsibility of the consumer.

The polling problem

One way to reduce that uncertainty is simply to ask more frequently.

The travel application could call the API every hour, every five minutes or every few seconds to determine whether the journey status has changed. Other applications interested in the same journey could independently do exactly the same.

This approach, known as polling, can be entirely appropriate in some scenarios, particularly when changes are infrequent or immediacy is not important. At enterprise scale, however, it introduces a trade-off between how quickly consumers discover change and how frequently they need to check for it.

If consumers poll infrequently, there is a longer period between something changing and the organisation becoming aware of it. If they poll continuously, the architecture generates repeated requests simply to discover that, most of the time, nothing has changed.

As the number of consumers and business processes grows, an organisation can therefore devote considerable activity to repeatedly asking systems about their current state rather than communicating the changes that actually matter.

This raises a different architectural question: what if consumers did not have to keep looking for change because meaningful change could announce itself?

From requesting information to knowing what happened

Events introduce a different interaction model. Rather than waiting for another system to request the latest state, a producer can publish a meaningful business event when that state changes. In our travel example, the operational system could publish: JourneyCancelled

The difference is more significant than simply replacing one integration technology with another. The API provides information when a consumer asks and the event communicates that something meaningful has already happened.

Once that event becomes available, different parts of the organisation can determine independently whether it matters to them. A customer communications service may notify affected passengers, a rebooking service may begin identifying alternatives, an operational dashboard may update disruption information and an analytics platform may record the cancellation for later analysis.

The originating system does not need to initiate each of those processes individually. Its responsibility is to make the meaningful business change available, while consumers determine how they should respond.

This creates a fundamentally different model of enterprise interaction. Instead of every consumer being responsible for discovering change, knowledge of that change can be distributed to the consumers that have expressed an interest in it.

APIs vs events: Different roles in a real-time enterprise

APIs and events are sometimes discussed as competing approaches to integration, but comparing them purely in terms of which technology is “better” misses the more important architectural distinction. They are designed to support different types of interaction.

An API typically begins with intent from the consumer. A system knows that it needs information or wants to invoke a capability, so it makes a request and receives a response. An event begins somewhere else: with a meaningful change in the business. Something has happened and that change can be communicated without waiting for every interested consumer to discover it independently.

The two models therefore answer different questions. An API can help a consumer understand what is true now or allow it to perform an action, while an event can tell the enterprise what has changed and create the opportunity for interested consumers to respond.

Consider the journey example. GET /journeys/123 allows an application to retrieve the latest information about that journey when it needs it. JourneyCancelled, by contrast, communicates that a meaningful change has already occurred.

Once a consumer receives that event, it may then use APIs to retrieve the passenger's booking, identify available alternatives or invoke another capability required to respond. The event does not need to contain every piece of information associated with the journey because its purpose is different: it creates awareness, while APIs provide controlled access to the context and capabilities required to act on that awareness.

The distinction is therefore not simply APIs or events. The more useful question is:

The goal is not to choose between APIs and events, but to use each interaction model where it creates the most value.

APIs capture business intent by allowing consumers to request information or invoke capabilities. Events represent business reality by communicating meaningful changes as they occur. Real-time enterprises need both.

Why real-time enterprises need APIs and events

The value of this combination becomes even clearer as the number and variety of consumers increases.

Publish once, subscribe many

Traditional integration is often designed around known relationships. One system produces information because another system requires it and that relationship becomes part of the integration architecture.

As additional consumers need the same information, additional relationships can emerge. APIs reduce much of this coupling by providing reusable interfaces through which multiple consumers can interact with a capability, but each consumer still needs to know what it requires and when to make the request.

As enterprise landscapes expand, those relationships can become increasingly difficult to manage. Mobile applications, analytics platforms, automation, AI, operational dashboards and partner systems may all need access to information originating from the same business process, often at different times and for completely different purposes.

Events introduce a different relationship through publish and subscribe.

When JourneyCancelled is published, the producer does not need to send separate instructions to customer communications, rebooking, operations and analytics. It publishes the business event once, while authorised consumers subscribe according to their own requirements.

This creates an important architectural characteristic: the producer does not need to know every consumer that may eventually find the event valuable.

A new consumer can potentially begin using the event later without requiring the originating system to be redesigned around that particular use case. An event initially created for an operational process may later become relevant to analytics, automation or an AI-powered service that did not exist when the event was first exposed.

Separating the business event from individual consumers therefore creates the potential for information to be reused beyond the purpose for which it was originally made available.

The architectural difference becomes particularly visible as the number of consumers grows.

Point-to-point relationships increase as new consumers and use cases are introduced. A publish-subscribe model allows a business event to be published once and consumed independently by multiple authorised subscribers.

The visual illustrates why this matters beyond technical elegance. In a point-to-point model, adding new consumers can require new connections, transformations and dependencies, increasing the effort required to change the architecture over time. In a publish-subscribe model, the producer makes the business event available independently of the consumers, allowing new subscribers to use that information without creating a bespoke relationship back to the originating application.

The objective is not simply to draw fewer lines on an architecture diagram. It is to reduce the dependency between the system where business activity occurs and the growing number of applications, services and processes that may need to know about it.

From notification to action

The value of combining APIs and events becomes particularly clear when we look beyond notification and consider what happens next.

An event can make a consumer aware that something meaningful has changed, but awareness alone may not provide everything required to make a decision or complete a process. The consumer may need additional context, or it may need to invoke another business capability before it can respond.

This is where APIs and events can work as part of the same interaction rather than as separate architectural approaches.

A consumer can receive an event to understand that something happened, use an API to retrieve the context it needs, and then invoke an API, automation or business process to take the appropriate action.

The result is an architecture in which information does not simply become available on demand. Meaningful change can initiate a chain of interactions across the enterprise, while APIs continue providing the controlled access and capabilities required to understand and respond to that change.

Not every business change should become an event

Recognising the value of events does not mean that every technical change occurring inside every application should suddenly become an enterprise event.

Doing so would create a different form of complexity. An organisation in which every database update, field change and internal application state is published may technically generate enormous amounts of real-time information, but consumers would then need to distinguish meaningful business activity from a flood of implementation detail.

The objective is therefore not simply to produce more events, but to identify and expose meaningful business events that describe changes other parts of the organisation may genuinely need to understand.

Business events need business meaning

Consider the difference between: DatabaseRowUpdated and: CustomerAccountSuspended

Both may accurately describe a change that occurred inside a system, but only one communicates why that change matters to the wider business.

The first exposes an implementation detail. Consumers need to understand the source application's data model before they can determine whether the update is relevant. The second describes a business occurrence that can be understood independently of the system that produced it and can therefore carry meaning across applications, teams and organisational boundaries.

That distinction becomes increasingly important as events are reused by more consumers. If every application needs detailed knowledge of the source system simply to interpret an event, much of the decoupling promised by event-driven architecture begins to disappear.

The same challenge becomes even more significant as automation and AI become part of the architecture. An intelligent service cannot respond reliably to enterprise activity simply because more data is moving in real time; it needs clear, governed and meaningful context about what that activity represents.

Real-time architecture therefore requires more than event transport. Organisations also need to consider how events are defined, discovered, governed and understood across the enterprise, particularly as those events become reusable beyond the systems and processes for which they were originally created.

From API connectivity to an event-aware enterprise

APIs transformed enterprise architecture by making business capabilities easier to expose, secure and reuse. Events extend that model by making meaningful business change easier to observe and respond to.

APIs expose what the business can do. Events communicate what the business has done.

Once organisations begin making those business events available at scale, however, another challenge appears.

Publishing an individual event is relatively straightforward. Making events available reliably across applications, clouds, environments, geographies and organisational boundaries, while allowing producers and consumers to remain decoupled, is a much larger architectural problem.

The question therefore moves from:

to:

That is the problem the next layer of the Beyond Batch architecture begins to address.

What could your enterprise know sooner?

Your organisation may already have access to the information it needs. The bigger opportunity is ensuring that meaningful change becomes visible while there is still time for that knowledge to influence decisions, experiences and actions across the business.

At Claria, we help organisations rethink how information moves and creates value across their technology landscape, bringing together integration, APIs, real-time data, automation and AI to build technology that can respond more effectively to the needs of the business.

Ready to explore where greater real-time awareness could create value across your enterprise?

Jamie Carter

Share