secture & code

Different uses of cache memory: Pros and Cons

We have always been told about caching, how it works, whether we should implement it or not... Or, simply, we have worked on projects in which it was already part of the infrastructure.

Well, today we are going to go a little deeper into it, seeing in a simple and concise way in which points of our application we can implement this cache, as well as the pros and cons of implementing it in those contexts.

With this we can get a more global vision about the use of it, and a reference point from which to start when we want (or not) to implement it.

Let's start with the basics...

What is cache memory

It is responsible for providing a high-speed storage system, used for data that will be required with a certain frequency and, moreover, will be transient. In this way, the data that we will consult in the future will be much faster to obtain.

Why use cache memory?

We will have quick access to the required data.
It reduces the load applied to the database (which is slower) of our application.
Better response time in our requests, thus improving the user experience.
We will reduce costs by avoiding many of the accesses to our database.

Why NOT use cache memory?

When we require real-time data with high accuracy, the use of caching can cause the consumption of stale data.
Including cache memory will add more complexity, since it is something more to take into account when maintaining and debugging.
It can add complexity when reproducing or searching for errors in our application.
Depending on the implementation, caching sensitive data can be a security issue.

Where to implement cache memory

Browser

To implement cache memory in the browser, we will use the header Cache-Control to which we can specify how we want our cache to behave (e.g. the lifetime of the cache with the parameter max-age=604800). Another option is the use of the Etag, which provides us with a unique identifier for each response, being able to identify if the response has changed and it is necessary to request the data again to our application.

We will save in requests to the backend (application).
Provides the ability to cache assets (html, css etc).
Of the three options, this is probably the simplest and quickest to implement.

The configuration only applies to the user/client making the request.
Not very flexible and not very adaptable to possible needs and use cases.
Misconfiguration of these headers can lead to security problems.

Reverse Proxy

In this case our cache memory will be implemented in the one that will work as an intermediary between the frontend (browser) and the backend (application). Our backend will determine the behavior of our cache inside the reverse proxy. For example, we could use several tools such as Redis o Nginx to implement it.

If you want to know more about how Reverse Proxy works, I invite you to read this other article API Gateway vs Load Balancer vs Reverse Proxy.

We can share and generalize the cache configuration among several clients.
We will continue to save requests to the backend.
We are still able to search assets.
The management of possible cache-related headers will not reach the backend and will be managed here.

Compared to the browser implementation, this can be somewhat more expensive to implement.
It remains inflexible and adaptable.

Application

We will now move on to implement our cache in the backend. This option gives us the possibility to implement it in the different layers of our application which, following a hexagonal architecture model, could be: the controller layer, the use case layer, or even the repository layer.

Just like using Reverse Proxy, we can do this implementation using the tool Redis.

If you want to know a little more about Hexagonal architecture, here is another article: Hexagonal Architecture 101.

This option is the most flexible, since it allows us to apply cache in very specific cases.
This implementation can be shared among several clients.
Depending on which layer we implement it in, we can reuse its configuration.
It is easy and accurate to test.

We will not save requests to the backend, and consequently we will perceive some more latency in terms of user experience.
It is not possible to cache assets.
Of the 3 options, it is the most complex to implement.

Conclusion

We could conclude this article by saying that the implementation of cache memory will always go hand in hand with the requirements and needs of our system. Depending on these, the need to implement it in the browser, reverse proxy or application will arise.

On the other hand, when we start implementing this type of technology, we must stop for a second and analyze why our system needs the implementation of cache memory, since the use of this, in many cases, is to try to «appease» possible performance problems. So the simple fact of having to use cache memory is an indicator that we must reformulate and rethink the operation of our system.

However, there are many other cases, as could be the case of working with a system Legacy in which the simple fact of applying this technology can help us to significantly improve its performance.

Bibliography