
I had a humble beginning with Amazon Dynamodb. I heard that DynamoDB was the place to store the sessions in a serverless environment. So I created a table.
Many recommended the session identifier (ID) as the Partition Key (PK) and a timestamp attribute to store the creation time. I thought it was so simple.
Soon, the sessions were flourishing in millions. Adding a session, reading a session took just a few milliseconds. I was happy!
One day, I asked myself, how would I block someone from using an old session? Easy! Fetch the session, check the timestamp. If old, then delete it from the table. I couldn’t be happier!
A month passed. A smart engineer joined the team with full of questions.
"So, how do you remove old sessions?" she asked casually. With a sigh of relief, I explained the process – fetch the session, check the timestamp, etc.
With a suspicious look, she continued her next question. "What happens to those sessions that never get re-used?".
Welcome to the world of TTL!
You only live twice in DynamoDB!!
What is TTL?
Time to Live (TTL) is a feature of DynamoDB. TTL allows you to set expiry for items (records if you are a SQLer) in a table. DynamoDB takes care of deleting those items that have gone past the expiry period.

Sounds simple, yet many who start using DynamoDB never look at this feature. Many become aware of it very late.
Even when they start using TTL, few never look into its details. They assume things and then get into troubleshooting problems.
This write-up is mainly for the benefit of those who are new to DynamoDB and would use TTL at some point.

Important TTL Tips
It’s free!
True, it does not cost anything to enable TTL on a table.
It is also free to set an expiry on items so that DynamoDB can remove the expired items in the background.
No performance impact
If you have a table with a busy traffic pattern and are worried about the performance, then it’s all fine.
DynamoDB does not consume the write capacity for deleting the expired items.
TTL is not for immediate item removal
This is the crucial aspect of TTL that many overlook.
Removal of an expired item does not happen on the dot. If your use case is to delete items at their exact expiry point, then TTL is not for you.
It can take up to 2 days to delete
Though the majority of the deletion happens within a reasonable period, AWS mentions that it can take up to 48 hours to remove an expired item.
Note that the items marked for deletion will still be available in the table during this period. Your application should be able to handle it by filtering out those.
Enabled on the table but set at item level
Though the TTL option is enabled at the table level and supplied with a TTL attribute name, you can set the value at each item level.
TTL period doesn’t need to be the same across the items, and you don’t need to set TTL in all either.
Unix epoch time format
The value set for TTL must be in Unix epoch time in seconds. It is important.
Any other format gets ignored by the background process that identifies and removes items.
Too old items live forever!
We mainly focus on setting expiry values that are in the future. However, TTL can represent past timestamp as well, but there is a limit on how far back we can go.
It is for five years! If you set a TTL value older than five years, then DynamoDB will not expire those items.
Combination of TTL and DynamoDB Streams
Before we explore the TTL use cases, let’s briefly look at DynamoDB Streams. As we will soon see, DynamoDB Streams gives TTL a new lease of life!
DynamoDB Streams is a powerful service that captures item-level updates in a table as an ordered sequence of events. There is an event for every item creation, update, and deletion.

When an item is deleted, either via user action or TTL, DynamoDB emits a deletion event. Handling the deletion event opens up possibilities for several use cases.
For a delete event triggered by TTL, the principal ID in the event data will show that it is DynamoDB that initiated the action. It is useful if you have granular event handling requirements.
DynamoDB Streams is an optional feature that needs enabling on a table.
Following are a few common serverless implementation patterns that use TTL.
TTL Extension
Use case: In an eCommerce application, many orders get abandoned before completion. Due to this, the checkout service stores the incomplete orders for a limited number of days only.
While creating an order, the checkout service sets the TTL to 7 days. If no further updates within this period, the order gets deleted by DynamoDB after seven days. If the customer updated the order, then the checkout service updates the TTL to be further seven days from that point.

The above is a pattern that applies to many use cases in different forms.
- In the above use case, the TTL can be removed from the item when an order is confirmed. It makes it not to expire or for another service to act on it at a later stage.
- A similar pattern is applicable with payments when an initially authorized one needs to go through a re-authorization process.
TTL Variation
Use case: A payment item contains data classified as general (NORMAL) and sensitive (PII). Sensitive data could be the customer’s address or card details, for example. While NORMAL data needs to stay longer, PII data needs removing sooner.
One approach for this is to split the item into two types (item-type), one for NORMAL
and the other for PII
. While the NORMAL
item is set with a long TTL duration, the PII
item is set with a shorter one, as shown below.

- This example showed that the TTL value does not need to be the same across the table. Items can have different TTL values or no TTL at all.
- The above approach eliminates the need for scheduled scans, item inspection, and updates to remove data.
Item Re-entry
Use case: Loan approval goes through several stages before the final decision. There can be information and documents attached to each of its stages. While the loan details get stored in DynamoDB, associated documents are likely to be kept in S3, with their location references updated in DynamoDB.
After the final decision, for a while, the data is kept before transferring to an archive or different storage. However, for a status reporting application, a minimal version of it is maintained in DynamoDB.
The TTL deletion (REMOVE
) event handler could inspect the item and create a new item, and inserts it in the same table.

- Depending on the business requirement, the newly created item may or may not have a TTL.
- There can be many variants of this use case. The data can be added to a different table in DynamoDB or to a different data store for analytical purposes.
Synchronizing Items
Use case: Many modern applications have event sourcing in place. For example, the payment goes through several stages, such as initialization, authorization, refund, cancellation, and settlement.
While a summary table keeps the latest state, another table serves as the event source that stores all the updates to that payment.
Setting a specific TTL duration that guarantees the removal of all the related items from the event source table can be a challenge. However, with a payment identifier, we can indirectly control the lifetime of the items in the event source table.
When the TTL deletion event of the summary item gets handled, the handler could act on all the event source entries for the same payment together.

- Though I mentioned deletion, the use cases vary depending on the domain and the business rules.
How TTL Benefits Your Application?
Reduces storage
It is natural that when we remove unwanted data from a table, the storage consumption reduces.
Though this won’t be visible with smaller datasets, tables that face high traffic load with thousands of new items added every minute, removal of old data plays a crucial role in keeping the storage low.
Reduces cost
As with the previous point, less storage costs less.
- First 25 GB stored per month is free
- $0.306 per GB-month thereafter (for Europe Frankfurt region)
In a production environment, you are likely to have a backup and restore option configured. It is also priced based on the storage size as well. Hence, controlling the data volume yields direct as well as indirect cost benefits.
Lighter query results
It must be a key motivator for using TTL. DynamoDB limits the result of a query or scan to 1 MB of data. If there are items that are of no value fetched by these queries, then these can pollute the results, thus affecting performance.
Reduces read capacity unit consumption
As with the lighter query results, fetching fewer data consumes less read capacity units (RCU). It is directly related to the cost.
If the unwanted items are also getting updated as part of your data operations, then it can cost even more. In DynamoDB, the writes are more expensive than the read operations.
Enables event-driven computing
TTL deletion events can act as triggers for many services. It promotes the decoupling of services and facilitates event-driven computing between microservices.
Functionless data deletion
TTL eliminates the need to run custom queries and expensive table scans by lambda functions to identify and delete items.
With TTL, the responsibility is transferred to the service provider, meaning less code to write (codeless), and that brings even more benefits.
Closing Thoughts
The beauty of engineering is that often the simple concepts, when expanded, become very valuable and powerful. DynamoDB’s TTL is such a simple feature that plays its part in building performant, scalable, and event-driven serverless architectures.
There are several use cases and architectural patterns built around DynamoDB TTL, from simple ones to complex ones that can schedule thousands of tasks.
If you have used TTL for a unique use case, then I would love to hear!