29 lines
1.5 KiB
Markdown
29 lines
1.5 KiB
Markdown
## Why
|
||
|
||
Reduce IO and external fetch load by adding a shared caching layer so repeated requests for the same content do not re-hit disk/network unnecessarily.
|
||
|
||
## What Changes
|
||
|
||
- Add a caching layer (Redis or similar lightweight cache) used by the site’s data/ingestion flows.
|
||
- Add a cache service to `docker-compose.yml`.
|
||
- Define an industry-standard cache invalidation interval (TTL) with a sensible default and allow it to be configured via environment variables.
|
||
- Add a script/command to manually clear the cache on demand.
|
||
- Add verification that the cache is working (cache hits/misses and TTL behavior).
|
||
|
||
## Capabilities
|
||
|
||
### New Capabilities
|
||
- `cache-layer`: Provide a shared caching service (Redis or equivalent) with TTL-based invalidation and a manual clear operation for the website’s data flows.
|
||
|
||
### Modified Capabilities
|
||
- `social-content-aggregation`: Use the cache layer to avoid re-fetching or re-processing external content sources on repeated runs/requests.
|
||
- `wordpress-content-source`: Use the cache layer to reduce repeated `wp-json` fetches and parsing work.
|
||
|
||
## Impact
|
||
|
||
- Deployment/local dev: add Redis (or equivalent) to `docker-compose.yml` and wire environment/config for connection + TTL.
|
||
- Scripts/services: update ingestion/build-time fetch to read/write via cache and log hit/miss for verification.
|
||
- Tooling: add a cache-clear script/command (and document usage).
|
||
- Testing: add tests or a lightweight verification step proving cached reads are used and expire as expected.
|
||
|