Member-only story
3 Ways to Retry Failures In Your Serverless Application
Learn how to handle errors in your event-driven workflows from a low, medium, and high level.
A few years ago when I got into serverless development and event driven architectures, there was so much of mystique and wonder. I didn’t know the purpose of an event bus, I couldn’t wrap my head around asynchronous processes, and I sure couldn’t figure out why you’d need to build retry functionality in an application.
Coming from a strictly synchronous background, retries made no sense. If something didn’t work, just click the button again. While this might be true for a synchronous API call, it is not the case in many serverless environments.
Serverless makes heavy use of events, which are asynchronous in nature. This means the caller does not wait to hear a response before returning. This is a highly effective approach when designing loosely-coupled systems that automatically scale under load. Not to mention it saves you some serious money when Lambda functions don’t have to wait for a process to finish.
When something goes wrong in an asynchronous process, you don’t want it to fail and be lost forever. It’s possible the process failed because of a transient error like a network failure or throttling event. These types of events can safely be retried and expected to go through (assuming the network issues cleared up or you’re under your rate limit).
If your app threw its hands up and said “I quit”, then you’d have needless data loss. We don’t want that.
This is so important in serverless applications that AWS includes it explicitly in the reliability pillar of the serverless application lens of the Well-Architected Framework.
Today we’re going to discuss three levels of retry-ability you can add to your app and the pros and cons of each.
Low-level Retries
AWS already handles a variety of failures for you when you invoke functions indirectly. It addresses the different invocation types with different types of retries.
However, when you are running synchronous invocations you’re on your own.
