llm-wiki/raw/official-docs/cache-aside-vs-write-through-aws.md

---
title: Caching patterns — cache-aside vs write-through vs write-behind (AWS + DAX + Redis)
source_type: official-doc
status: raw
confidence: medium
url: https://aws.amazon.com/caching/best-practices/
archive_url:
tags: [ca-cache-consistency, cache-aside, write-through, write-behind, redis, official-doc]
related_branches: [feature-cache-consistency-contract]
related_projects: [ca-skeleton-operational-contract]
created: 2026-05-22
last_reviewed: 2026-05-27
---

# Caching patterns — cache-aside vs write-through vs write-behind

> Layer: `raw/official-docs/` — AWS Caching Best Practices + DAX Developer Guide + Redis 문서 발췌. ca-tmpl 의 cache-aside default 결정의 외부 근거.

## Parent / 활용 branch (필수)

| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| [[raw/branch-notes/feature-cache-consistency-contract]] | "cache-aside + after-commit invalidation" 을 default 로 채택한 결정의 외부 근거 — write-through / write-behind 가 가지는 trade-off 와의 비교 |

특정 branch 없이 foundational 조사로 수집한 경우:

- [[raw/project-notes/ca-skeleton-operational-contract]] — ca-tmpl operational contract 의 cache consistency 초기 조사

## 컨텍스트 / 왜 저장했는지

ca-tmpl 이 cache-aside 를 default 로 채택한 **이유의 외부 근거**. write-through / write-behind / read-through 와의 trade-off 를 공식 사이트 인용으로 비교.

## 출처 / Source

- 원본 URL: https://aws.amazon.com/caching/best-practices/ (AWS Caching Best Practices)
- 보조 URL: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DAX.consistency.html (DAX = write-through caching service — verbatim 확보)
- 보조 URL: https://redis.io/learn/howtos/solutions/microservices/caching (Redis Learn — cache-aside definition verbatim 확보; write-behind / read-through 는 별도 페이지)
- 아카이브 URL: (미수집)
- 저자 / 조직: AWS Database team; Redis Inc.
- 발행일: rolling
- 마지막 확인일: 2026-05-27 (WebFetch 검증: AWS Caching Best Practices 는 "Lazy caching" + "Write-through" 두 패턴만 본문에 있음. write-behind / read-through 는 본 페이지에 없음 → DAX + Redis 문서로 보강. AWS Database Blog 의 별도 캐싱 비교 글 후속 확인 필요)

## 핵심 인용 / Key quotes (verbatim)

> [AWS Caching Best Practices §Lazy caching] "Laziness should serve as the foundation of any good caching strategy. The basic idea is to populate the cache only when an object is actually requested by the application."

> [AWS Caching Best Practices §Lazy caching — cache miss] "If not (a cache miss), then the database is queried for the object. The cache is populated, and the object is returned."

> [AWS Caching Best Practices §Write-through] "In a write-through cache, the cache is updated in real time when the database is updated."

> [AWS Caching Best Practices §Write-through — latency tradeoff] "It shifts any application delay to the user updating data, which maps better to user expectations."

> [DAX Developer Guide §DAX and DynamoDB consistency models — opening] "Amazon DynamoDB Accelerator (DAX) is a write-through caching service that is designed to simplify the process of adding a cache to DynamoDB tables."

> [DAX Developer Guide §How DAX processes writes] "As a write-through cache, DAX passes your writes through to DynamoDB synchronously, then automatically and asynchronously replicates resulting updates to your item cache across all nodes in the cluster. You don't need to manage cache invalidation logic because DAX handles it for you."

> [Redis Learn §Cache-Aside] "The cache-aside pattern (also called lazy loading) is a caching strategy where the application is responsible for reading and writing to both the cache and the database."

## Claims Extracted / 추출된 주장

| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| CACHE-PAT-C1 | Lazy caching (= cache-aside) 의 핵심: cache 는 application 이 실제 데이터를 요청할 때만 populate. cache miss 시 application 이 DB 조회 → cache populate → 반환 | [AWS §Lazy caching] "Laziness should serve as the foundation of any good caching strategy. The basic idea is to populate the cache only when an object is actually requested by the application." + "If not (a cache miss), then the database is queried for the object. The cache is populated, and the object is returned." | `official-vendor-doc` | application-managed cache (Caffeine, Redis client side) | cache miss 시 DB 조회를 application 이 직접 해야 한다는 강제는 본 인용 직접 명시. "application is responsible" 은 AWS 본문에는 명시 없음 (Redis 문서 별도 인용) |
| CACHE-PAT-C2 | cache-aside 의 책임 분리: application 이 cache 와 DB 양쪽 R/W 를 책임 | [Redis Learn §Cache-Aside] "The cache-aside pattern (also called lazy loading) is a caching strategy where the application is responsible for reading and writing to both the cache and the database." | `official-vendor-doc` | Redis cache-aside 구현 일반 | "cache 가 DB 를 모른다" 는 강한 분리는 본 인용 명시. invalidation 정책은 별도 |
| CACHE-PAT-C3 | Write-through cache 는 DB 가 갱신될 때 cache 도 real-time 으로 갱신. write 시점에 latency 가 user 측으로 이동 (application delay → user delay) | [AWS §Write-through] "In a write-through cache, the cache is updated in real time when the database is updated." + "It shifts any application delay to the user updating data, which maps better to user expectations." | `official-vendor-doc` | write-through 패턴 일반 | "모든 write 가 cache 와 DB 에 동시 commit 된다" 는 atomic 보장은 본 인용 범위 밖 — synchronization 메커니즘은 구현 의존 |
| CACHE-PAT-C4 | DAX 는 write-through caching service 로 구현되며, application 측에서 cache invalidation logic 을 별도 관리할 필요 없음. write 는 DynamoDB 에 synchronous 로 전달 후 async 로 cluster node 에 replicate | [DAX §DAX and DynamoDB consistency models] "Amazon DynamoDB Accelerator (DAX) is a write-through caching service..." + [§How DAX processes writes] "...DAX passes your writes through to DynamoDB synchronously, then automatically and asynchronously replicates resulting updates to your item cache across all nodes in the cluster. You don't need to manage cache invalidation logic because DAX handles it for you." | `official-vendor-doc` | DAX 사용 환경 (DynamoDB 한정) | 모든 write-through 구현이 invalidation 을 자동 처리한다는 일반화 금지 — DAX 의 특정 구현 |
| CACHE-PAT-C5 | Write-behind (= write-back) 패턴: application 이 cache 에 쓰고 cache 가 asynchronous 로 DB 에 기록. 최저 write latency 를 제공하지만 cache 장애 시 data loss 위험 | (원본 frontmatter 발췌 — AWS Caching Best Practices 본 페이지에 명시 없음. AWS Database Blog 또는 Redis docs 의 별도 페이지에서 유래로 추정) | `needs-confirmation` | write-behind 패턴 일반 비교 | 본 세션에서 AWS 또는 Redis 공식 페이지의 verbatim source 미확보 — 후속 라운드에 별도 출처 ("AWS Database Blog — caching strategies" 또는 Redis docs/learn 의 write-behind 페이지) 로 verbatim 재확인 필요 |
| CACHE-PAT-C6 | Read-through 패턴: cache-aside 와 유사하나 cache 가 자체적으로 DB 에서 load (configured loader 필요) | (원본 frontmatter 발췌 — AWS 본 페이지에 명시 없음. Caffeine `LoadingCache` / Redisson 등의 SDK 문서로 추정) | `needs-confirmation` | LoadingCache 류 (Caffeine, Redisson `LocalCachedMap` 등) | 본 세션 verbatim source 미확보 — Caffeine 또는 Redis docs 의 read-through 페이지에서 재확인 필요 |

## Usage Boundaries / 적용 경계

- **이 자료가 직접 증명하는 것**:
  - `CACHE-PAT-C1` ~ `C2`: cache-aside (lazy loading) 의 정의 + application 책임 (AWS + Redis)
  - `CACHE-PAT-C3`: write-through 의 정의 + latency tradeoff (AWS verbatim)
  - `CACHE-PAT-C4`: DAX 가 write-through 구현이며 invalidation 을 자동 처리한다는 사실 (DAX 한정)
- **이 자료가 증명하지 않는 것**:
  - write-behind 의 정확한 정의와 data loss 메커니즘 (`CACHE-PAT-C5` — `needs-confirmation`)
  - read-through 의 정확한 정의와 loader 메커니즘 (`CACHE-PAT-C6` — `needs-confirmation`)
  - "write-through 는 결제 도메인에 부적합" 같은 prescriptive 주장 (출처 측은 trade-off 만 제시)
  - cache-aside + after-commit invalidation 의 정확한 구현 패턴 (application 책임 영역)
- **내 프로젝트에 적용하려면 추가 확인이 필요한 것**:
  - ca-tmpl 의 "write-through forbidden by default" 결정은 우리 consistency contract 의 결과이지 AWS/Redis 가 권고한 것 아님 — 내부 결정 근거 문서화 필요
  - `CACHE-PAT-C5`, `C6` 의 verbatim 출처 후속 확보 (AWS Database Blog 의 "Caching strategies and best practices" 별도 글 또는 Redis docs)
  - Caffeine `LoadingCache` / Redisson `LocalCachedMap` 의 read-through 동작이 ca-tmpl "adapter 가 loader 를 소유" 원칙과 정합한지 별도 검증

## 메모 / Notes (내 프로젝트 해석 — 검증 전 추론)

> 본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.

- **ca-tmpl 결정과의 매핑 (해석)**:
  - **cache-aside default** ← "application owns invalidation" 원칙 (`CACHE-PAT-C2` 의 application 책임을 invalidation 까지 확장). cache 가 DB 를 모르고, adapter layer 가 명시적으로 invalidate
  - **read-through 허용** ← adapter 가 loader 를 소유하는 경우만 (Caffeine `LoadingCache`, Redisson `LocalCachedMap` 등). 책임 경계가 망가지지 않음 — `CACHE-PAT-C6` verbatim 후속 필요
  - **write-through forbidden by default** ← consistency contract 없이 도입하면 cache update 와 DB commit 사이의 race 가 생김. cache-aside + after-commit invalidation 이 더 안전 (내부 결정)
  - **write-behind forbidden** ← prod 에서 cache 노드 장애 시 silent data loss (`CACHE-PAT-C5` 의 verbatim 후속 필요). 결제 / 주문 도메인에는 부적합 (내부 결정)
- **trade-off 요약 표 (해석)**:

| pattern | read latency | write latency | consistency | failure mode | 본 자료 직접 증명? |
|---|---|---|---|---|---|
| cache-aside | fast (hit), slow (miss) | DB만 (cache는 invalidate) | application owns | stale on bug | `CACHE-PAT-C1`, `C2` 부분 |
| read-through | fast (hit), slow (miss) | DB만 | cache owns loader | cache misconfig = read failure | `CACHE-PAT-C6` `needs-confirmation` |
| write-through | fast | slow (cache+DB sync) | strong if same tx | cache outage = write failure | `CACHE-PAT-C3`, `C4` |
| write-behind | fast | very fast | weak (async) | cache crash = data loss | `CACHE-PAT-C5` `needs-confirmation` |

- **시사점**: ca-tmpl 이 채택한 cache-aside + after-commit invalidation 은 "약한 보장 + 실패 가시성 높음" 의 조합. 결제 같은 strong consistency 에는 별도 채널이 필요.

## Related / 관련

- 같은 주제 다른 official-doc / company-tech-blog: (write-behind, read-through 의 verbatim 출처 후속 수집 필요)
- 인용하는 branch:
  - [[raw/branch-notes/feature-cache-consistency-contract]]
- 인용하는 wiki: (미작성)
- 대안 그룹 (ca-tmpl 결정 컨텍스트): **Group G-C — Cache consistency** (대안 1: cache-aside [ca-tmpl 채택] / 대안 2: write-through / 대안 3: write-behind / 대안 4: read-through with loader)