AWS takes a lot of heat for its product names, usually becasue they're weird, and that's especially true for EventBridge but for a different reason. EventBridge is often marketed as the successor for Cloudwatch events, but that description greatly undersells the service. EventBridge is more than just a relay for things which happened, it is by any defintion a fully-fledged enterprise service bus, and is worthy of consideration with Kafka or MuleSoft or other event-based messaging platforms.
In Services Oriented Architecture, an Enterprise Service Bus is actually a compound pattern realizing seven other subpatterns. Someone somewhere knew what they were doing when they designed EventBridge because every ESB subpattern can be realized with an EventBridge feature. Here's how the features line up to the patterns:
| SOA Subpattern | EventBridge Feature |
|---|---|
| Asynchronous Queuing | EventBridge can use SQS as a destination to queue events before sending to the consumers, as shown in this pattern: https://serverlessland.com/patterns/eventbridge-sqs |
| Event-driven Messaging | As a consumer, EventBridge has direct integration with over 130 AWS sources, plus a number of third party SaaS platforms. Direct integration with the API Gateway as well as a dirext PutEvents API allows for integration from custom sources. EventBridge supports 35 targets, including API Gateway destinations for custom integrations. |
| Intermediate Routing | A rules engine filters events and routes messages to one or more targets. |
| Policy Centralization | EventBridge has a schema registry, supporting either OpenAPI or JSON-Schema. Code bindings for several languages can be downloaded from the schema registry. |
| Reliable Messaging | EventBridge offers at-least once delivery, with retry and durable storage across multiple availability zones. EventBridge also features archive and replay of events. |
| Rules Centralization | Routing and transformation rules are localized to a single service |
| Service Broker | The Service Broker pattern is itself a compound pattern, composed of the Data Format Transformation, Data Model Transformation and Protocol Bridging patterns. EventBridge transformation rules realize Data Format Transformation and Data Model Transformation, while Protocol Bridging occurs mainly with API Gateway integrations |
It's hard to understate the value of API endpoints. These realize Service Loose Coupling, which makes EventBridge completely agnostic to whatever language or application is being used by producers and consumers. There are no proprietary protocols, libraries or config languages beyond HTTP. This allows easy integration across applications, business units or even cloud providers.
Many purpose-built ESBs require a great deal of infrastructure and team members to support them, but EventBridge is serverless. There is no infrastructure to manage, and no capacity to plan around other than the limits documented at https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-quota.html.
EventBridge itself can be configured in a matter of minutes, and with its direct integrations to so many AWS services events can be flowing shortly thereafter. Accomplishing so much in a single iteration is a tremendous boost to systems integration.
In addition to its documentaion, EventBridge is also supported by a number of patterns on Serverlessland, at https://serverlessland.com/patterns?services=eventbridge.
With its speed to implement and ESB-fulfilling features, EventBridge deserves consideration alongside other messaging systems.
Top comments (0)