Cache invalidation in serverless applications

Question

I'm trying to implement a user service that has a GET and PUT API using AWS lambda , API gateway and Dynamo as the datastore

GET API will fetch the data for a given userId and PUT will update the user details for a given userId

My requirements are

• since the throughput on the GET APIs are large I would need to cache the API response so that the response time is reduced in the subsequent requests. cache will also need to have a TTL.

• Any successful put request on the same userId will invalidate the cache and subsequent GET request will fetch from DB and cache it again

• I could possibly use a redis cluster for caching. But that might add addition VPC invocation overhead

Question:

• I'm using AWS lambda using serverless framework for the implementation. How should I go about designing the caching layer?
• Possible solutions include API gateway caching - But in this method how would I invalidate a cache incase of update requests

Answer 1

You could cache at the API Gateway layer and invalidate the cache by sending a Cache-Control: max-age=0 header to API Gateway (for example, from the Lambda that is altering DynamoDB records during PUT requests). You would need to grant specific IAM permissions for that to work. Keep in mind that you can only invalidate 1000 requests per month for free; after that, you'll be charged $0.005 per path invalidated.

CloudFront has similar caching and invalidation options, but you can probably get all the same caching options from just API Gateway directly.

Another option would be to cache at the DynamoDB layer, using DynamoDB Accelerator. It provides significant retrieval improvements to DynamoDB requests and handles invalidation for you. Maintainability-wise, it's hard to get a better option. The downside is you won't bring the latency down as much as if you use CloudFront or API Gateway caching.

Lastly, you can also look into ElastiCache, which you would access from your Lambda function. But given the overhead of writing/reading/invalidating the cache yourself, the other options are probably more maintainable in the long term.

You may find the AWS Caching Overview helpful in coming up with more ways to cache, depending on your needs.