By Dustin Herboldshimer
Sep 04, 2024
By Dustin Herboldshimer
Sep 04, 2024
Facilitating Event Driven Architecture Evolution Using Amazon EventBridge
At Olio Apps EventBridge has become a huge topic of conversation ever since we’ve been using it with one of our clients. Initially, our client’s architecture followed a synchronous inline model where you give the server a request and then it does A, B, C, D, and E.
As the app continues to grow, it becomes harder to manage all of these different threads and if-thens. So we've shifted to utilize AWS event-driven architecture, a first for this client. Initially, we integrated with SQS queues (Amazon Simple Queuing Service) to manage asynchronous job processing. Since then we have begun to shift more and more to event driven architecture patterns.
And as stated in AWS’ documentation EventBridge can handle input from a variety of AWS sources or from a custom event bus.
In particular, we provisioned our AWS resources using the serverless framework and used a combination of EventBridge’s rules, event matching, and routing capabilities to enable a user experience informed by the context of these specific events.
Facilitating Event Driven Architecture Evolution using Amazon EventBridge
Some of you may recognize this paradigm. Initially, we needed to trigger notifications based on specific factors like the day of the week, how long it had been since a certain event happened, or a user’s relationship to one another. So we began to utilize a serverless event bus, Amazon EventBridge, to listen, schedule, & trigger these events. EventBridge Listener would wait for specific events to enter the event bus. Once they did, this would trigger a corresponding lambda function to take the event to an SQS queue where it would then be processed asynchronously. The above description is essentially the base use case described by AWS’ official illustrations. This image shows the event bus and the different events being pumped into it from specific sources.
And as stated in AWS’ documentation EventBridge can handle input from a variety of AWS sources or from a custom event bus.
In particular, we provisioned our AWS resources using the serverless framework and used a combination of EventBridge’s rules, event matching, and routing capabilities to enable a user experience informed by the context of these specific events.
Value of Eventbridge
In summary this is how EventBridge functions as we have events flowing into the pipeline with the following orchestration. Rules: We define rules within EventBridge that act as event filters. These rules can listen for specific events, like "user created" or "user updated." Event Matching: Each rule is configured with an event pattern. This pattern specifies the data characteristics and the rule it is looking for. For instance, a rule might match events where the "detail-type" property equals "user-updated" and the "source" property equals "staging-API." Routing Events: When an event matches a rule's pattern, EventBridge routes it to a designated target. This target can be a Lambda function that we've previously defined to handle the event. Imagine a rule named "user-updated-event-bridge-rule." This rule intercepts events flowing through the pipeline, searching for events that match its criteria (detail-type="user-updated" and source="staging-API"). If an event doesn't match, it's simply passed along. However, if a match occurs, the event is directed to the Lambda function associated with that rule. This Lambda function executes the desired logic based on the received event data. A major reason EventBridge has been so valuable for our client’s event driven architecture is because of EventBridge’s robust flexibility, including: Multiple Rules per Event: A single event can be matched by multiple rules, allowing for diverse processing paths. Multiple Targets per Rule: Each rule can route events to up to five different targets, enabling parallel processing or sending events to various services. Event Data: We can include any relevant data within the event itself. This allows Lambda functions to perform actions based on the differences between old and new data (e.g., detecting a user's change in profile information). This ability to define custom rules and targets empowered us to make intricate event workflows that fit our client’s needs. Currently, we have Lambda functions that trigger additional events based on the processed data, sending them back into the EventBridge pipeline for further processing of 3rd party APIs. This is one example where we are able to leverage the vast capabilities of EventBridge for enabling event driven architecture. for building sophisticated event-driven architectures using EventBridge. Overall, this EventBridge architecture has allowed us to offload all these semi-heavy computational side effects when there is a profile update to the cloud. So we're not taking a bunch of performance hits by running everything in line on individual requests. We hope you enjoyed our discussion on how Olio Apps is utilizing EventBridge to meet customer needs using event driven architecture on AWS. If you have any questions about using EventBridge yourself or have any questions about how your application may be able to utilize EventBridge, please don’t hesitate to contact us.Dustin Herboldshimer
Engineering Manager
Dustin is a developer specializing in React web applications, working on the full application stack (CSS, components, redux/saga backend). He enjoys sipping good bourbon, sci-fi, and family time.
Share This Post
Popular Articles
