Using DynamoDB as a Cache - What You Need To Know

Introduction – Caching in DynamoDB

The ever-growing need for faster scalable web applications is necessary for caching. Caching is storing data for reuse, reducing the time taken for the content served to the users. In addition, caching done within DynamoDB offloads the database operations from heavy operations; thus, the front-end clients could retrieve the data faster and improve user experience.

How Does Caching Work in DynamoDB?

AWS provides a natively optimized caching service for DynamoDB called DAX (DynamoDB Accelerator). When the server performs a request to query data from a DynamoDB database, the DAX will first check it to see if it has the results of the query within its cache. If yes, the data is returned immediately from the DAX without being queried from the DynamoDB table.

However, suppose the results are not available within the cache maintained by DAX. In that case, it will send the query to the database, respond to the server with the results provided by the database, and automatically synchronize the data from DynamoDB to the DAX. This way, the next time the application sends the same query, DAX will respond to the query instead of fetching the results from the DynamoDB database.

The advantage of this process is that the complete synchronization and management of DAX are provisioned and carried out by AWS!

When To Use Caching in DynamoDB?

DynamoDB caching can significantly increase performance even if the number of requests exceeds millions of requests per second.

It would help if you only used caching in DynamoDB when:

1. As an in-memory cache to increase performance and reduce response times of eventually consistent read workloads from single-digit milliseconds to microseconds.
2. To reduce operational and application complexity by providing a managed service that is API-compatible with DynamoDB. As a result, it will only require minimal functional changes to use with an existing application.
3. For read-heavy or unpredictable spikes of workloads to provide resources for increasing throughput and potential cost savings by reducing the need to provision more read capacity units within DynamoDB
4. Caching should only be used when the application is read-intensive applications. Caching is not the ideal solution in cases where data is processed in the background and does not need to be retrieved frequently like data warehousing.

Caching Strategies

You can consider multiple strategies when implementing caching for your applications that use DynamoDB.

The following are the most commonly used caching strategies:

1. Read-Through
2. Write-Through
3. Write-Behind

Read-Through

The Read-Through caching strategy is also known as Lazy Loading. Applications using the Read-Through/Lazy Loading caching strategy consider the cache the main database. Therefore, when looking up a specific item, the application will hit the cache first; if the data is not available within the cache, the cache pulls the data from the main database and updates it.

Data Flow will follow the steps mentioned below:

1. Application searches cache for data.
2. If the application finds the data within the cache, then the cache returns the data to the application.
3. If the application does not find the data within the cache, the cache looks up the data from the database.
4. The database then populates the cache with the data.
5. The eviction policy then ensures that only new data will populate the cache.

Write-Through

This caching strategy is similar to the Read-Through caching strategy. However, the application writes the data directly to the cache and not the main database; the application would write the cache and back to the main database. Therefore, this write operation completes synchronously and will impact the write latency.

Data Flow will follow the steps mentioned below:

1. The application will write the data to the cache.
2. The cache then updates the database.
3. After the database updates itself, it sends an "ack," sent via the cache to the application.
4. The eviction policy then ensures that only new data will populate the cache.

Write-Behind

Write-Behind caching strategy takes a similar approach to Write-Through. However, it writes the data directly to the main database asynchronously instead of the cache. It effectively lowers the write latency since it is only limited to the latency of the cache; however, since the cache is volatile, there is a chance that the data written to the cache may get lost if the cache becomes unavailable or becomes unresponsive.

Data Flow will follow the steps mentioned below:

1. The application writes the data to the cache, sending an "ack" for the write operation.
2. The cache will only update the database asynchronously.
3. The database acknowledges the cache regarding the successful write operation.
4. The eviction policy then ensures that only new data will populate the cache.

Cache Eviction

Cache eviction refers to how the system removes items that are no longer fit to be stored within the cache to stop the cache from growing uncontrollably.

AWS DAX handles this task in three different ways. First, it uses TTL (Time-to-Live) value to decide the maximum lifespan of a specific value within the cache. Second, the DAX removes the values stored within the cache by using a Least Recently Used (LRU) algorithm when the cache is full. Third, the DAX will remove the old values as new values get written through the DAX using the write-through functionality. Finally, using a single API call helps keep the DAX item cache consistent with the underlying data store.

DynamoDB Cache vs Redis

What is Redis?

Redis is an open-source NoSQL database known for being a fast, in-memory data store, message broker, cache, and queue. It also delivers sub-millisecond response times even when processing millions of requests, making it perfect for large-scale applications such as gaming, social media, session management, real-time analytics, etc.

Advantages of using Redis

1. Open source license. Redis is free to use and deploy on any machine or cloud that you prefer.
2. Ease of configuration. Redis offers easy to deploy configuration that supports LRU (Least Recently Used) and LFU (Least Frequently Used) algorithms for effective caching.
3. Rich data structures. Redis supports five possible data options for values: hashes, lists, sets, strings, and sorted sets.
4. Persistence of data. Redis supports point-in-time backups to provide persistence in addition to in-memory caching.
5. Scalability. Redis allows expanding at scale without any impact on the availability and performance.
6. Store large items. Redis enables storing items up to 512 MB.

Advantages of using DynamoDB

1. A part of the AWS managed services. DynamoDB is a fully managed AWS service and is easier to create and manage complicated architectures since the cloud service provider natively supports it.
2. Scalability. Since DynamoDB runs on AWS infrastructure, users can leverage its scalability to expand storage and performance to store virtually unlimited amounts of data.
3. Redundancy. DynamoDB allows users to set up high availability by using AWS's existing features, such as availability zones.
4. Includes Free Tier. AWS DynamoDB provides a one-year subscription to their free tier that allows users to use the service for free; restrictions do apply, but you can utilize all the credits provided within the free tier before you have to pay for the service.
5. Inbuilt Security. DynamoDB provides proven security controls for encryption, authentication, and security for its underlying AWS infrastructure so that you need not have to worry about implementing the essential security controls.

Disadvantages of using Redis

1. Expensive when scaling. Since Redis uses RAM to store its data, expanding would mean that you'd need an excessive amount of RAM, which can be costly.
2. Lacks basic Authorization controls. You cannot implement RBAC (Role-Based-Access-Control) within the free version, and it is only available within the enterprise subscription
3. No in-built encryption. Redis does not support native encryption functionality.

Disadvantages of using DynamoDB

1. Only available on AWS. DynamoDB is only available on AWS as a service, and you will not be able to deploy this service on any other cloud service provider or on-premise servers.
2. DAX is only compatible with DynamoDB, and therefore you cannot use any other database other than DynamoDB
3. Direct writing to DAX can be slower. Writing data to the DAX can be slower than writing the same data set directly to the database.
4. DAX helps Read-Intensive applications. DAX improves speeds for a read-intensive application; however, it does not do the same for a Write-Intensive application
5. Difficult to query data. Querying data is hugely limited due to the native architecture of the database.

What to use for your workload?

If your workloads and applications run on AWS and you have already decided to use DynamoDB as your database. Then using DAX along with your DynamoDB database would give you a boost for all the reads that your application would perform and reduce response times. The combination of DynamoDB and DAX already has a proven track record of running complicated and resource-intensive workloads for large organizations.

Redis provides an open-source solution that has already proven its effectiveness in the enterprise. If your workload does not run predominantly on AWS or DynamoDB, then you have the option of using Redis to leverage its functionalities.

Conclusion

This article covered the basic concepts of using AWS DynamoDB for caching and what you need to know before building your application.

I hope you have found this helpful. Thank you for reading!

Frequently Asked Questions

Is Caching necessary for DynamoDB?

No, caching is not necessary for using DynamoDB. You will still get 10-20 millisecond, if not single-digit millisecond response times for your read requests. However, if you add caching by using AWS DAX, the response times for database read operations can see a decrease to values within the range of microseconds.

Is DynamoDB useful for Session Caching?

Yes, DynamoDB is helpful for managing sessions and session caching within your applications. You may refer to the .NET application session caching example provided by AWS for more information.

Can DynamoDB cache be 4MB?

Yes, DynamoDB supports a maximum size of 4MB per transactional request; therefore, the cache can be up to 4MB but not exceed this limit. In addition, another restriction is where the maximum number of unique items per transactional request cannot exceed 25 unique items.