쓰기 요청이 오면 캐시와 DB를 함께 갱신하고, DB 기록까지 끝난 뒤에 완료로 응답하는 전략. 캐시를 "거쳐서(through)" DB로 쓴다.
동작 순서
- ① 애플리케이션 → 캐시에 쓰기 요청
- ② 캐시가 자기 값 갱신
- ③ 캐시가 곧바로 DB에도 기록 ← 여기서 기다린다
- ④ DB 기록 완료 후에야 응답
③에서 기다린다는 점이 Write-Back과 갈리는 결정적 차이다.
시간 순으로 보면
Write-Through : |── 캐시 쓰기 ──|── DB 쓰기 ──| 응답
Write-Back : |── 캐시 쓰기 ──| 응답 …나중에 DB 쓰기
얻는 것
- 캐시와 DB가 항상 같다. 읽기에서 낡은 값을 볼 일이 없다.
- 캐시가 갑자기 죽어도 DB에 이미 다 반영돼 있어 유실이 없다.
대가
- 쓰기 지연이 늘어난다. 매 쓰기가 DB 응답을 기다린다. 쓰기가 많으면 불리하다.
- 다시 안 읽힐 데이터까지 캐시에 올라간다. 한 번 쓰고 조회되지 않는 로그성 데이터라면 메모리 낭비다 → TTL을 함께 두거나 Write-Around를 쓴다.
네 전략 비교
| 전략 | 쓸 때 하는 일 | 유실 위험 | 쓰기 지연 | 캐시 오염 |
|---|---|---|---|---|
| Write-Through | 캐시 + DB 동시 | 없음 | 큼 | 있음 |
| Write-Back | 캐시만, DB는 나중 | 있음 | 작음 | 있음 |
| Write-Around | DB만(캐시 건너뜀) | 없음 | 작음 | 없음 |
| Cache-Aside 쓰기 | DB 갱신 + 캐시 삭제 | 없음 | 작음 | 없음 |
언제 고르나
정합성이 지연보다 중요하고, 쓴 뒤 곧 읽히는 데이터. 회원 등급·설정값처럼 한 번 바꾸면 자주 조회되는 것이 맞다.
반대로 조회수·로그처럼 쓰기가 폭주하고 즉시 읽히지 않는 데이터에는 Write-Back이나 Write-Around가 낫다.
CPU 캐시에서 온 용어
원래 CPU와 메인 메모리 사이의 캐시 정책 용어다. 애플리케이션 캐시(Redis)에도 같은 이름을 빌려 쓴다 — 임베디드·컴퓨터구조에서 만나는 write-through/write-back과 같은 개념이다.