Event Brokers as Event API Gateways – Bridging the Asynchronous Gap

For REST APIs, we’ve long had API gateways — but what about events and event APIs? API gateways have been the trusted gatekeepers for REST APIs for many years — handling everything from authentication and traffic shaping to content transformation.

But what does that mean for Events and event APIs? Well, the good news is that the core of event-driven architecture (EDA) — the event broker — includes many of the same gateway capabilities. For example, it can mediate protocols, enforce policies, and manage access to event streams.

In this post, I’ll explore how unified API management with Solace Event Portal elevates Solace Event Brokers into the role of event API gateways. I’ll look at how Solace Event Portal and Solace Event Brokers compare to traditional API gateways, what kinds of runtime policies they can enforce, and how event mesh topologies can help securely expose event APIs — even in public-facing or lower-security zones.

What Should an Event API Gateway Do?

There’s a growing consensus in the industry — including from folks like Fran Méndez of AsyncAPI — that event API gateways need to handle a few key responsibilities:

• Protocol translation
• Event security
• Traffic control

Other capabilities like schema validation, event transformation, and observability are important too, but for now, let’s focus on the three pillars that matter most when it comes to runtime behavior and policy enforcement.

As for developer experience and portals — we’ve covered those in detail before in this post, so we won’t cover them in detail here.

Capabilities for Unified API Management

This diagram depicts the capabilities required for unified API management.

Solace Event Portal is the central hub for unified API management. event APIs are designed here and exposed to an API Governance layer that supports all API styles required by an organization.

The event APIs and event API Products defined in Event Portal also define the policies that are applied at runtime when a client gains access to event APIs. Event Brokers act as the policy enforcement points for these clients.

The API Governance layer is responsible to expose APIs of all styles in Developer Portals for self -service access by developers.

In this blog we are concentrating on the event API gateway capabilities that the combination of Event Portal and Brokers provide.

Event Brokers and API Gateways: “Same, Same, But Different”

At first glance, event brokers and API gateways appear to serve a similar purpose — they both sit between producers and consumers, acting as intermediaries that manage communication.

But under the hood, they operate differently — especially when it comes to how they handle traffic and allocate resources.

HTTP API gateways are designed to protect backend services by throttling requests, enforcing rate limits, and caching responses. They’re optimized for synchronous, request/response interactions.

Event brokers, on the other hand, are built for asynchronous communication. Their mechanism to protect resources is to absorb and distribute messages as fast as possible — often with delivery guarantees.

While API gateways are mostly network and CPU-bound, event brokers are also disk-bound — thanks to their role in storing, retaining, and replaying events which is reflected in the type of traffic control policies you need to apply to event API gateways. Different tools, different constraints.

Protocol Mediation

One of the most important jobs of an event API gateway is protocol mediation — the ability to translate between different communication protocols and technologies. This is where Solace event brokers really shine.

Solace event brokers offer native support for multiple open protocols and APIs. This includes commonly used web protocols like REST/HTTP, or WebSocket, as well as native event protocols such as AMQP, MQTT, and JMS. This flexibility means developers can connect modern cloud-native apps, legacy systems, and IoT devices without needing to worry about protocol translation.

Protocol mediation bridges the gap between diverse systems — enabling seamless communication across different protocols, data formats, and technologies.

Solace also ensures at least once delivery guarantees — something that’s often lost when translating to less reliable protocols like HTTP as implemented by many traditional API Gateways that offer event gateway functionality. Unlike many REST API gateways, Solace’s REST and WebSocket support is built to preserve these guarantees, even across protocol boundaries.

Event Security

Security is a must-have for any API gateway — and it’s no different for event APIs. Solace event brokers bring strong security features to the table, helping to protect event streams from unauthorized access or tampering.

Solace supports a wide range of authentication options — from basic auth with LDAP or internal user stores, to OAuth2 and mutual TLS using client certificates.

You can also define policies such as IP allow/deny lists and Access Control (ACLs) to restrict which parts of the topic hierarchy a client can access.

Beyond access, Solace lets you define fine-grained client permissions and resource limits — like how many connections or subscriptions a client can have.

These policies can be defined in the Solace Event Portal by designing event API Products and enforced directly on the broker — even when it’s deployed at the edge (like in a DMZ). That means you can securely expose event APIs to external clients while keeping tight control over what gets in and out.

With event API Products, you can go even further — tailoring access for specific client groups. For instance, you might allow a partner to receive stock updates, but only for a specific region. These products help you define and enforce policies at a business level.

Traffic Control

Just like REST APIs, event APIs need traffic control — but the way it’s handled in event-driven systems is a bit different. Traditional API gateways throttle requests to protect backend services. Event brokers, on the other hand, are built to absorb and distribute messages as fast as possible. Their bottlenecks aren’t usually primarily CPU or network — they’re also about disk usage, especially when it comes to message retention.

Policies offered by Solace Platform:

• Flow Control Policies:  Event brokers have inherent capabilities to control ingress and egress flows.
• Client-Specific Resource Management: Define how many queues, subscriptions, or concurrent connections a client can use. This helps ensure fair usage and system stability.
• Guaranteed Messaging Quotas: Brokers provide specific resource allocation for guaranteed delivery, including defining a Maximum Spool Size and Maximum Time-To-Live (TTL) for event retention. This lets you define SLAs for different client tiers: “at least once” delivery with longer retention for premium clients, or “at most once” for freemium users.
• Caching Policies: Last Value Queues and MQTT Retain features let consumers pick up the latest value even if they weren’t online when it was published — like HTTP response caching.

Unlike HTTP gateways, event brokers don’t usually rely on rate limiting or spike arrest. Instead, Solace is designed to scale — with clustering and burst-handling features that help it absorb large volumes of traffic.

The Event Mesh: Distributing events within your organization and beyond

The full potential of Solace Event Brokers as event API gateways is unlocked when they are deployed as part of an event Mesh. An event mesh is a distributed architecture composed of interconnected brokers that enables dynamic, real-time routing of events between applications — whether they are deployed on-premises, in private data centers, or across public clouds. Solace enables this by linking brokers across environments, allowing applications connected to any node in the mesh to exchange events seamlessly.

This topology also provides a mechanism to expose specific brokers as gateway nodes for event API access. When deployed in lower-trust zones such as DMZs or public-facing subnets, these brokers can serve as secure ingress points into the event mesh.

These gateway brokers can enforce runtime policies at the edge, including SLAs, access permissions, and endpoint configurations. All these policies can be centrally defined in the Event Portal and enforced locally on the broker, ensuring consistent governance across the mesh.

Therefore, a broker deployed in a DMZ can authenticate and authorize external clients, apply resource limits, and validate access before any events are allowed to propagate into the core enterprise environment.

Solace’s event mesh functionality is based on dynamic message routing (DMR) — a mechanism that enables brokers to automatically discover and route events across the event mesh. DMR is self-routing, self-learning, and self-healing, allowing for resilient and efficient event distribution across the enterprise.

This dynamic routing ensures that clients interacting with a public-facing broker do not need to be aware of the internal topology. At the same time, you can apply directional controls to restrict event distribution — for example, preventing sensitive data from flowing into lower-security zones or limiting external visibility into internal topics. This directional control is highlighted in the graphic above.

Extending The Event Mesh: Event APIs and distribution for Legacy Event Brokers

As we’ve seen, Solace Platform is well-suited for distributing events and exposing them to event API clients. But many organizations also rely on legacy or third-party messaging systems — such as IBM MQ and Apache Kafka. Or they leverage cloud providers’ technologies such as Amazon Kinesis or Azure Event Hubs. How do you bring event distribution and event APIs to these?

Solace provides a range of integration options — including a native Kafka bridge and a library of micro-integrations — to connect these systems into a unified event mesh. You can explore these options in Solace Integration Hub.

Integrating legacy brokers into the mesh not only enables event distribution and event API access — it also allows you to enrich events with smart topic structures. This makes it easier to govern which events are exposed in event APIs and gives clients fine-grained control over what they subscribe to.

For example, a single Kafka topic like “Global.Orders” can be transformed into a structured event stream using smart topics — enabling developers to subscribe only to the regions, product lines, or order types they care about.

The diagram below shows how Kafka or IBM MQ brokers can be connected to an event mesh built with Solace Platform — unlocking those events and making them accessible across your organization (and externally) through event APIs.

Conclusion

Event API gateways already exist —through the capabilities of Solace Event Brokers governed and controlled by Event Portal. Solace brokers serve as powerful enforcement points for runtime policies, including security, connection management, and resource allocation.

When deployed as part of an event mesh, Solace brokers become dynamic, self-routing gateways. Positioned at the edge, they can securely expose event APIs to external clients, while the mesh handles intelligent routing and policy enforcement across the wider enterprise.