adr.zone

ADR Example: Redis for application read-through cache (ISO 42010–inspired 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

Use Redis for short-lived application caching

Architecture description record (ISO/IEC/IEEE 42010–inspired). Lightweight, Git-friendly fields. Not a full conformance report to the standard—use the vocabulary of stakeholders, concerns, and views to align the decision with the architecture description.

Record ID (cross-ref): ADR-42010-0028

System / subject scope

Public API tier, Redis cluster shared with session use cases, primary relational store as authority.

Stakeholders and roles

API teams, SRE, DB owners, security for key material if any.

Stakeholder concerns (to be addressed in the architecture description)

Latency, cost of repeated reads, correctness on eviction, security of cache key namespaces.

View and viewpoint (what is shown, and from which perspective)

Viewpoint: runtime / performance. View: per-route caching policy, Redis namespaces, and failure degradation paths.

Decision

Place a Redis-backed read-through cache for TTL-bound data where routes are allowlisted. Authoritative state remains in the primary database; eviction and miss paths must be correct.

Rationale (with respect to the concerns and alternatives)

The architecture description for request handling should show where acceleration exists without pretending Redis is a store of record. Concerns: speed vs staleness; mitigations: TTL, key design, and runbooks for flush.

Architectural impact (elements, relationships, and operational follow-through)

Code paths add cache get/set; metrics for miss/hit; load tests for Redis down scenarios.

Traceability (requirements, policy, SLOs, other ADRs)

SRE runbook for Redis; ADR for next cache allowlist change.