Torben Sorensen
d004efb84b
All checks were successful
Deploy to Test Environment / deploy-to-test (push) Successful in 16m21s
23 lines
1.2 KiB
Markdown
23 lines
1.2 KiB
Markdown
# ADR-009: Caching Strategy for Read-Heavy Operations
|
|
|
|
**Date**: 2025-12-12
|
|
|
|
**Status**: Proposed
|
|
|
|
## Context
|
|
|
|
The application has several read-heavy endpoints (e.g., getting flyer items, recipes, brands). As traffic increases, these endpoints will put significant load on the database, even for data that changes infrequently.
|
|
|
|
## Decision
|
|
|
|
We will implement a multi-layered caching strategy using an in-memory data store like **Redis**.
|
|
|
|
1. **Define Cacheable Data**: Identify data suitable for caching (e.g., flyer data, recipe details, brand lists).
|
|
2. **Define Invalidation Strategy**: Determine the cache invalidation strategy (e.g., time-to-live (TTL), event-based invalidation on data update).
|
|
3. **Implement Cache-Aside Pattern**: The repository layer will be updated to implement a "Cache-Aside" pattern, where methods first check Redis for data before falling back to the database.
|
|
|
|
## Consequences
|
|
|
|
**Positive**: Directly addresses application performance and scalability. Reduces database load and improves API response times for common requests.
|
|
**Negative**: Introduces Redis as a dependency if not already used. Adds complexity to the data-fetching logic and requires careful management of cache invalidation to prevent stale data.
|