Skip to main content

Mutation Based Cache Invalidation with Resilis

In this article, you will learn how caching works with API hosted and optimized on Resilis technology. If you are looking for an explainer of what Resilis is and does, you should check this intro first. If you want to know how to get started optimizing your API using Resilis, you can check our Postman collection guide or the OpenAPI guide.

This guide will walk you through what the caching feature does, explain mutation-based invalidation of cache, its implications for your API requests, and how it can help boost your API performance to save cost and reduce latency.

Prerequisites

To follow through with this guide, you will need the following:

  • A Resils account. Sign up here.
  • A basic knowledge of APIs.
  • Already deployed Resilis API. Check the guides above to learn how to deploy one.

API Response Caching

Caching involves storing frequently accessed data along the request-response path, a key architectural constraint in REST APIs. When a client requests resources, the system checks a cache; if updated data is present, it satisfies the request, otherwise, data is fetched from the server.

API caching enhances performance by storing responses for a specific period, reducing latency and server load. This optimization allows for quicker and more efficient communication between various software systems in modern web applications, ensuring speed and efficiency, especially for repeated requests.

Mutation Based Invalidation of Cache

Resilis caches API response through our globally distributed edge servers that bring API responses closer to users, reducing latency and amplifying performance. Resilis also purges caches in real-time based on API usage behavior.

You can configure your Resilis API to invalidate(purge) caches when a change in data happens. This feature is called Mutation Based Invalidation. It can be applied of mutating endpoints like POST, PUT, and DELETE. The cache purge or invalidation in Resilis are of two kinds: Tag Based and ID Based.

Tag Based Cache Invalidation: In tag based cache invalidation, the endpoints to be purged are not directly related to the mutating endpoint either by slug or id. When non-relating endpoints are configured to be purged after a mutation happens in the parent endpoint(mutating endpoint), Resilis group them by tag and invalidate their caches. Here is how to configure it:

  • Go to a mutating endpoint and click on the more option, click Edit and you will get a display like the one below. The Purge input has a dropdown of the GET endpoints that you want to clear its cache when the mutating endpoint request is resolved.

  • In the dropdown, you will select non related endpoint like the GET api/v1/posts endpoint. Resilis will group it together with the mutating endpoint by tag and purge the cache whenever a new post is made.

ID Based Invalidation: In ID based cache invalidation, the endpoints to be purged are related to the mutating endpoint by ID. For example, when a user PUT request which mutates the user data happens to a particular user through Id, you will want to purge the cache for all GET responses that uses same user Id because the user data have changed. An example of the setup is shown below:

tip

You can add multiple endpoints to the purge input as required by your business logic whether tag based or ID based invalidation.