adr.zone

ADR Example: Redis for application read-through cache (Y-Statement 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

Y-Statement (structured decision record)

Sentence

In the context of API read hot paths and repeated database access, facing latency without false confidence in cache as truth, we have decided for Redis for short-lived read-through cache entries with strict keying and invalidation in order to faster user-visible paths with TTL discipline and the DB as authority, accepting that we accept Redis as an operational component and more careful review of cache code.

Fields (same content, for reviews)

  • Context: API read hot paths and repeated database access
  • Concern: latency without false confidence in cache as truth
  • Stance / subject: for / Redis for short-lived read-through cache entries with strict keying and invalidation
  • Intended outcome: faster user-visible paths with TTL discipline and the DB as authority
  • Deliberate tradeoff: we accept Redis as an operational component and more careful review of cache code