Read-through, Write-through와 Write-behind

Overview

캐시 패턴은 “누가 DB를 읽고, 쓰기 성공을 언제 응답하며, 캐시와 원본 중 누가 진실인가”를 정한다. 이름보다 실제 구현의 책임과 실패 순서를 먼저 그려야 한다.

핵심 용어

왜 필요한가

읽기가 많은 기준정보와 쓰기가 많은 집계 데이터는 같은 정책이 맞지 않는다. 최신성이 중요한 가격과 잠시 오래되어도 되는 공휴일 정보도 다르다. 패턴은 데이터 특성에 맞춘 책임 경계를 만든다.

핵심 원리와 내부 동작

Read-through는 Loader를 Cache 계층에 숨긴다. Write-through는 원본 성공 전 응답하지 않으며 두 저장소 중 하나만 실패할 수 있어 보상 규칙이 필요하다. Write-behind는 Queue/Buffer가 내구성과 순서를 담당해야 하며 Cache를 잃으면 미반영 쓰기를 잃을 수 있다.

flowchart LR; A[Application] --> C[Cache]; C -->|Read-through miss| D[(DB)]; A -->|Write-through| C; C --> D; A -->|Write-behind ack| C; C -.async flush.-> D

Example

상품 상세는 Cache-aside + DB Commit 후 Evict가 단순하다. 실시간 Counter는 Redis에서 원자 증가 후 Stream/Queue로 DB에 Flush할 수 있지만, Redis 장애 시 유실 허용 범위와 중복 Flush 멱등성을 먼저 정의한다.

DB commit 성공 → cache delete 실패
대응: 짧은 TTL + 삭제 재시도/이벤트 + stale 허용 시간 경보

실무에서 발생하는 문제와 Trade-off

Write-through는 쓰기 경로의 Network Hop과 두 저장소 장애를 늘린다. Write-behind는 Backlog, Crash Recovery, 같은 Key의 순서, Batch 부분 실패가 핵심이다. Read-through Loader가 느리면 Cache Thread Pool이 포화될 수 있다.

흔한 오해

• Write-through가 두 저장소의 분산 원자성을 자동 보장하지 않는다.
• Write-behind는 단순 비동기가 아니라 내구성 있는 Queue와 Replay가 필요한 데이터 파이프라인이다.
• Spring @CachePut 이름만으로 저장소 소유권 전략이 결정되는 것은 아니다.

Production Considerations

Cache/DB 성공 조합별 동작표를 만든다. Write-behind Lag, Queue 크기, Flush 실패·재시도·중복을 관찰하고 종료 시 Drain 정책을 둔다. Source of Truth와 Recovery 순서를 Runbook에 명시한다.

다른 사람에게 설명한다면

30초: “Read-through는 캐시가 원본 읽기를 대신하고, Write-through는 캐시와 DB 쓰기를 동기 완료한 뒤 응답합니다. Write-behind는 캐시에 먼저 쓰고 DB는 비동기 반영해 빠르지만 유실과 순서 복구가 어렵습니다.”

2분: 각 패턴의 응답 시점, Source of Truth, 한쪽 실패, 재기동 복구를 표로 비교하고 데이터 최신성·쓰기량에 따라 선택한다고 설명한다.

Interview Questions

1. Cache-aside와 Read-through의 책임 차이는?
2. Write-through의 부분 실패를 어떻게 다룰 것인가?
3. Write-behind에 왜 Durable Queue가 필요한가?
4. Write-around가 적합한 데이터는?

Related Topics

Cache-aside, 캐시 정합성과 실패 패턴을 함께 본다.