Event Driven Architectures With EventBridge

I’m seeing more and more articles each week about event driven architectures and for good reason, they provide loose coupling of components, scalability and flexibility, essentially giving you an evolutionary architecture.

Fortunately, building event driven architectures with AWS has become really easy since the release of EventBridge.

As I mentioned in my last post EventBridge is a key part of our trial provisioning system as shown in figure 1 below.

Figure 1.

We have a Lambda function processing the DynamoDB event stream converting INSERT events into a “TrialRequested” EventBridge event and REMOVE events triggered by TTL into a “TrialExpired” EventBridge event.

Our “OnlineTrial” events have a common structure (see example below) which get sent to a custom EventBridge event bus. We send the event name in the “DetailType” property and always set the “Source” property to “OnlineTrial”.

{
   "version": "1.0",
   "trialId": "40ea41b6-4b85-40c0-a185-1ad825d8dc13",
   "leadId": "1234567890",
   "type": "ACS",
   "requestedAt": 1589379579,
   "status": "REQUESTED"
}

From that point on the whole system is driven by EventBridge rules triggering various Lambda functions.

The “TrialRequested” event triggers the Assign Trial Lambda function which in turn executes the Step Function I explained in an earlier post, the final task of that state machine generates one of two events, either a “TrialAssigned” or “TrialAssignmentFailed” event.

The “TrialAssigned”, “TrialAssignmentFailed” and “TrialExpired” events all trigger Lambda functions that manage the CloudFormation stacks that represent trial environments, creating new “warm” trials when trials are assigned and deleting them when they expire or fail to setup correctly.

One advantage of an event driven architecture allows your Lambda functions to separate concerns by doing one thing and one thing only. For example, rather than every individual Lambda function having to send metrics to CloudWatch we centralise this processing to a single Lambda function that solely manages metrics for the system.

Adding new functionality is also extremely easy in event driven systems as existing functionality doesn’t need to change to add new capabilities, for example, if we decide to store trial requests in a data lake for later analysis or we want to send notifications to Slack when a new trial is assigned we only need to implement a new Lambda function and configure an additional EventBridge rule.

I’m really happy with the approach we’ve taken and will definitely lean towards an event-driven approach with any future systems we implement.