Security Cloud Privacy Tech
Making Sure Events Don't Drop In The AWS Cloud

Making Sure Events Don't Drop In The AWS Cloud

Event-driven architectures can be really powerful.

A critical aspect of these designs is properly handling the events that drive the solution. You want to make sure that your design gracefully handles events that can’t be processed when they are emitted.

There are a few patterns to do this. This Twitter thread ๐Ÿ‘‡ looks at two methods to address this challenge using Amazon EventBridge.

Tweet 1/11 ๐Ÿ‘‡ Next tweet

one of the most critical aspects of an event-driven system is making sure that events don't fall on the floor

there are two general paths to take here:

  • make sure unhandled events can be replayed
  • make sure that unhandled events can be resent

๐Ÿงต #cloud #devops

Tweet 2/11 ๐Ÿ‘‡ Next tweet ๐Ÿ‘† Start

for most use cases, replaying or parking events is a more elegant solution
  • there are use cases where resending unhandled events is the better path, it entirely depends on what the event is describing

let’s look at a two ways to implement this @awscloud

๐Ÿงต #cloud #devops

Tweet 3/11 ๐Ÿ‘‡ Next tweet ๐Ÿ‘† Start

@awscloud the first: dead-letter queues in Amazon Eventbridge

the docs are up at

๐Ÿงต #cloud #devops

Tweet 4/11 ๐Ÿ‘‡ Next tweet ๐Ÿ‘† Start

@awscloud EventBridge dead-letter queues (DLQ) are actually SQS queues under the covers

you don’t have to worry about that but it’s handy to know, because it does open up some possibilities

EventBridge DLQ can be used when EventBridge can’t fire a trigger for an event

๐Ÿงต #cloud #devops

Tweet 5/11 ๐Ÿ‘‡ Next tweet ๐Ÿ‘† Start

@awscloud by default, EventBridge will try to send an event again for up to 24 hours or 185 times...whichever comes first

when that happens, EventBridge can drop the event to a DLQ

  • you can send them to the DLQ directly on 1st fail too

๐Ÿงต #cloud #devops

Tweet 6/11 ๐Ÿ‘‡ Next tweet ๐Ÿ‘† Start

@awscloud events in the DLQ can then be drained directly from an @awscloud Lambda function or you could use your own logic to handle them

…use Lambda

more at

๐Ÿงต #cloud #devops

Tweet 7/11 ๐Ÿ‘‡ Next tweet ๐Ÿ‘† Start

@awscloud so a DLQ will help you park events in order to resend them

the 2nd pattern is to use EventBridge’s archive feature…yes, it has an archive feature

the docs are up at

๐Ÿงต #cloud #devops

Tweet 8/11 ๐Ÿ‘‡ Next tweet ๐Ÿ‘† Start

@awscloud the archive is another event target. it has a configurable retention period after which events are deleted

once events are in the archive, you can use the replay feature to…um…replay them

docs at

๐Ÿงต #cloud #devops

Tweet 9/11 ๐Ÿ‘‡ Next tweet ๐Ÿ‘† Start

@awscloud now the DLQ is a lot more flexible and should be your go-to when trying to avoid dropping events

…but the archive is really interesting. the replay feature is good for series of events over a set timeframe. for some use cases, this is the way to go

๐Ÿงต #cloud #devops

Tweet 10/11 ๐Ÿ‘‡ Next tweet ๐Ÿ‘† Start

@awscloud regardless of the approach, most event-driven solutions don't want to lose events

making sure that your design can deal with those unhandled events effectively is critical to a reslient design

๐Ÿงต #cloud #devops

Tweet 11/11 ๐Ÿ‘‡ Next tweet ๐Ÿ‘† Start

@awscloud this is also another example of why you should be reading the docs when you using any cloud service

honestly, I had no idea that the archive feature existed in EventBridge. glad i stumbled across it today!

/๐Ÿงต #cloud #devops

More Content