ADR Example: Redis for application read-through cache (Nygard ADR format)

A concrete architecture decision example for using Redis to shave latency on hot read paths while keeping the relational store the source of truth. Below is the same decision in Nygard, MADR, Y-Statement, or an ISO-42010–inspired record—use the format toggle to compare structure, not just wording.

When this type of decision shows up

You repeat the same read queries and need bounded TTL-based caching, not a second system of record.
You already run Redis for adjacent workloads and can reuse operational playbooks and failover practice.
Reviewers need cache invalidation and key design treated as correctness, not a performance afterthought.

Format

Preview

ADR-0028: Use Redis for short-lived application caching

Status

Accepted

Context

Hot read paths repeat the same queries against primary storage. We need lower tail latency on a subset of endpoints without making the database a de facto cache with unclear invalidation.

Redis is already deployed for session and rate limits; SRE has failover playbooks.

Decision

Use Redis for short-lived, TTL-bound read-through caching on approved endpoints. Redis is not a system of record: on miss or eviction, behavior stays correct by reading the authoritative store. Cache keys must include all dimensions that affect correctness (tenant, flags, etc.).

Consequences

Positive: fewer hot-path reads; clear place to add breakers. Negative: another runtime; stale data if invalidation is wrong—reviewers treat cache as correctness-critical. Operational: cap memory, naming convention, and a flush runbook for regional incidents.