When you execute your code within AWS Lambda, the functions can either be invoked synchronously or asynchronously. While each is useful and needed for different situations, they also come along with interesting side effects in the serverless space.

Synchronous functions are used when you need to know the result of an operation before moving on to the next one. This might be something as simple as invoking one function that does a calculation and then using the result in another function. Synchronous functions can be easier to handle and keep track of because they are usually invoked one at a time in order. They allow you to get the result of a function before moving on to the next one so you don’t have to worry about missing data.

Sometimes, however, it doesn’t actually matter what the response is; it is good enough to know that the function has been fired and is running. When this is the case, asynchronous functions are the way to go. One example of when you would want to run an asynchronous function is when you are starting a video encoding process. AWS Lambda will send a response that the video encoding function has been invoked and started successfully. Because the function is asynchronous, you get this response as soon as the process has been started, instead of having to wait until the process has completed.

Within AWS Lambda, functions invoked synchronously and asynchronously are handled in different ways when they fail, which can cause some unexpected side effects in your program logic. If you are synchronously invoking functions directly, the invoking application is responsible for all retries. If you are using integrations they may have additional retries built in. Functions that are invoked asynchronously don’t rely on the invoking application for retries. In this case, the retries are built in and run automatically. The invocation will be retried twice with delays in-between. If it fails on both retries, the event is discarded. With asynchronous invocations, you are able to set up a Dead Letter Queue which can be used to keep the failed event from being discarded. The Dead Letter Queue allows you to send unprocessed events to an Amazon SQSor SNS queue for you to build logic to deal with.

Whichever type of invocation you choose to use for your AWS Lambda functions, it is very important that you understand how the service is going to handle failures. Building your own logic for retries can end up conflicting with the built in handlers and cause some very interesting behavior!