New – Archive and Replay Events with Amazon EventBridge

Event-driven architectures use events to share information between the components of one or more applications. Events tell us that “something has happened”, maybe you received an API request, a file has been uploaded to a storage platform, or a database record has been updated.

Source: New – Archive and Replay Events with Amazon EventBridge

Business events describe something related to your activities, for example that a new customer account has been created, or a payment has been successful.

To connect applications together using events from your own applications, integrated Software-as-a-Service (SaaS) applications, and AWS services, you can use Amazon EventBridge, a serverless event bus that delivers a stream of real-time data from event sources, and routes that data to targets like AWS Lambda.

Events tell us a fact that can be shared with whoever is interested in that piece of information. When a new customer account has been created, this information can be used by new services that are being added, without having to change existing interfaces. For example, a new fraud detection system can be interested in knowing all new customer accounts as they are created to perform security checks and evaluate possible fraudulent activities.

Sometimes you may need to reprocess past events. There are many use cases where this is useful, for example:

• After you fix a bug, you can reprocess the impacted events to get the correct result. This approach assumes that your application can process the same event multiple times.
• When you release a new feature, you can reprocess previous events to extend the reach of the feature to past data. For instance, a fraud detection system that has been added to your application can not only have access to new accounts, but also past accounts that were created in the previous weeks or months.

To make this easier, I am happy to share that EventBridge can now archive and replay events:

• You can now create an encrypted archive of the events published to an event bus. You can archive all events, or filter them using the same pattern matching syntax used by EventBridge rules. You can store events indefinitely, or set up a retention period after which older events are automatically removed from the archive.
• You can also replay the events stored in an archive. Events are replayed to all rules defined for the event bus (but not to managed rules created by other AWS services) or to the rules you specify. Replayed events contain an extra  replay-name field in case you need to recognize them. When starting a replay, you define a time frame, and only events within that time frame are replayed. Currently, you can only replay events to the same event bus from which they were archived.

Archives and replays work with all events process by EventBridge, including eventsfrom the AWS platform, from SaaS integrations, and your own custom events.

During replays, your current event throughput is unaffected, because EventBridge is keeping a separate quota for replays. The speed of a replay, in terms of eventspublished per second, is the same as your current PutEvents limits in the region. If you ask to increase your PutEvents service quota, replays will be faster. In this way, your normal operations are not affected by a replay. However, you should check performance and limits of downstream services processing the replay to be sure they can handle the additional workload.

You can stop an in-progress replay. You can’t resume a stopped replay, but you can create a new replay with the start time set to the lastReplayedEvent timestamp from a previously stopped replay.

Let’s see how archives and replays work in practice.

Creating an Event Archive
In the EventBridge console, I create an event bus for my application.

Then, I create a rule for the event bus with a simple event matching pattern to send all events it receives with DetailType equal to customerCreated to a Lambda function storing the customer data in the event into a database.

Now, I select the event bus and then, in the Actions menu, Archive events.

I give the archive a name and description, and I double check that the source is my event bus. I select an infinite retention period, but you can choose a number of days to retain, after which the events are automatically removed from the archive.

I select Next. I can optionally filter the events to archive with a pattern matching syntax similar to the one I used before when creating the rule. I decide to not add any filter and archive all events from the source.

Now, I use this simple Python code to put some events in the bus:

import json
import boto3

EVENT_BUS = 'my-event-bus'

# Create EventBridge client

events = boto3.client('events')

eventDetail  = {
    'customerId': '123',
    'customerName': 'Danilo',
    'customerData': 'More info...'
}

# Put an event
response = events.put_events(
    Entries=[
        {
            'EventBusName': EVENT_BUS,
            'Detail': json.dumps(eventDetail),
            'DetailType': 'customerCreated',
            'Source': 'com.mycompany.myapp'
        }
    ]
)
print(response['Entries'])

I run the previous code multiple times. After a few minutes, I see that the events I published have been archived:

Replaying Events
After some time, I discover a bug in the code of my Lambda function… The function is not storing all the data when the address is longer than expected (yes, these things happen ). I fix the code, so that new events are processed correctly. Using EventBridge, I can also replay older events to fix the result for the ones I already processed.

I can safely do so because my application is idempotent. That means it can be executed multiple times with the same input without changing the result. In this case, it’ll overwrite the database items with the correct customer data. To build a resilient application, I always suggest to design an idempotent interface. In this way, you can easily recover from errors like this one, and you can also safely ignore duplicate inputs.

Note that EventBridge does not provide ordering guarantees, and replays are performed in a multi-threaded manner that might result in events being delivered in an order different from that of their original ordering.

With my archive selected, I click on Start new replay and give the replay a name and description.

I check that the source of the replay is my archive. I select to replay only the rule triggering the Lambda function where the bug was fixed.

I define the start and end time for the replay (I can use local time or UTC) and select Start Replay.

Well, my archive is not that big. When the replay starts, it only takes a few seconds to complete. I look at my database, and the customer data is now correct. Bug fixed!

Available Now
Events archive and replay is available today in all commercial regions with the exception of Mainland China and Osaka.  You can use these new features with the console, the AWS Command Line Interface (CLI),  the AWS SDKs, and AWS CloudFormation.

With Amazon EventBridge, you only pay for what you use. For archive and replay, you pay by the number of events archived, the storage used by the archives, and the number of messages replayed.

Let me know what you are going to use these new features for