How to invalidate AWS APIGateway cache

Question

We have a service which inserts into dynamodb certain values. For sake of this question let's say its key:value pair i.e., customer_id:customer_email. The inserts don't happen that frequently and once the inserts are done, that specific key doesn't get updated.

What we have done is create a client library which, provided with customer_id will fetch customer_email from dynamodb.

Given that customer_id data is static, what we were thinking is to add cache to the table but one thing which we are not sure that what will happen in the following use-case

1. client_1 uses our library to fetch customer_email for customer_id = 2.
2. The customer doesn't exist so API Gateway returns not found
3. APIGateway will cache this response
4. For any subsequent calls, this cached response will be sent
5. Now another system inserts customer_id = 2 with its email id. This system doesn't know if this response has been cached previously or not. It doesn't even know that any other system has fetched this specific data. How can we invalidate cache for this specific customer_id when it gets inserted into dynamodb

Answer 1

You can send a request to the API endpoint with a Cache-Control: max-age=0 header which will cause it to refresh.

This could open your application up to attack as a bad actor can simply flood an expensive endpoint with lots of traffic and buckle your servers/database. In order to safeguard against that it's best to use a signed request.

In case it's useful to people, here's .NET code to create the signed request:

https://gist.github.com/secretorange/905b4811300d7c96c71fa9c6d115ee24

Answer 2

We've built a Lambda which takes care of re-filling cache with updated results. It's a quite manual process, with very little re-usable code, but it works.

Lambda is triggered by the application itself following application needs. For example, in CRUD operations the Lambda is triggered upon successful execution of POST, PATCH and DELETE on a specific resource, in order to clear the general GET request (i.e. clear GET /books whenever POST /book succeeded).

Unfortunately, if you have a View with a server-side paginated table you are going to face all sorts of issues because invalidating /books is not enough since you actually may have /books?page=2, /books?page=3 and so on....a nightmare!

I believe APIG should allow for more granular control of cache entries, otherwise many use cases aren't covered. It would be enough if they would allow to choose a root cache group for each request, so that we could manage cache entries by group rather than by single request (which, imho, is also less common).