opcotech/elemo

# Caching and Cache Invalidation

| author      | created at | updated at | status   |
|:------------|:-----------|------------|:---------|
| gabor-boros | 2023-05-02 | -          | accepted |

## Abstract

The goal of this ADR is to define a caching strategy for the application. Since
Neo4j is [slower than its competitors], we have to use caching to improve the
response time of the application.

The cache strategy for now shouldn't be complex or sophisticated. We should
start with a simple solution and improve it later if it's necessary. The cache
strategy should be easy to implement and maintain.

The implementation must handle the following cases:

- The related cache must be invalidated when a new node is created.
- The related cache must be updated when a node is updated.
- The related cache must be invalidated when a node is deleted.
- The related cache must be invalidated when a relationship is created.
- The related cache must be invalidated when a relationship is deleted.

[slower than its competitors]: https://memgraph.com/benchgraph/base

## Decision

The application will use Redis as a cache store and will use the [Cache Aside
Pattern] to manage the cache. The caching is handled using [go-redis/cache] and
[redis/go-redis] to implement repository-layer caching.

Whenever a node is created, updated, or deleted, the related cache will be
evicted. The same applies to relationships. When we need to evict the cache, and
we cannot determine the related cache exactly, we delete all the caches related
to the resource to be on the safe side.

The cache key is composed of the resource, resource ID, and other parameters
if available. For example, the cache key for the `GET /api/v1/todos/:id`
endpoint is `todo:<ID>`. The cache key for the `GET /api/v1/todos?offset=0&limit=1`
endpoint is `todo:<OFFSET>:<LIMIT>`.

[Cache Aside Pattern]: https://docs.microsoft.com/en-us/azure/architecture/patterns/cache-aside

## Consequences

The application will be faster, and the response time will be improved by 
magnitudes. On the other hand, the application will be more complex due to cache
invalidation, and it increases the monthly costs by using Redis.

Also, the cache invalidation strategy will result in frequent cache evictions,
and cache misses, but it's not a problem for now. We can improve the cache
invalidation strategy later if it's necessary.

In the future, we can use cache hit/miss monitoring to have a better insight.

## References

None.