Write-Through 전략

1. Write-Throgh 전략이란?

Write-Through는 데이터를 저장할 때 캐시와 DB에 동시에(Simultaneously) 업데이트를 진행하는 방식이다.

캐시를 단순히 임시 저장소가 아닌 메인 저장소의 거울처럼 취급한다.

동작 흐름

1. Write Request: 애플리케이션이 새로운 데이터를 저장하거나 기존 데이터를 수정한다.
2. Cache Update: 먼저 캐시(Redis)에 데이터를 쓴다.
3. DB Update: 이어서 DB에도 데이터를 쓴다.
4. Response: 두 곳 모두 저장이 완료되면 애플리케이션에 성공 응답을 보낸다.

2. Spring Boot 코드 예시

Spring에서는 @CachePut어노테이션을 사용하여 이 전략을 구현한다. @Cacheable이 캐시에 데이터가 있으면 메서드를 실행하지 않는 것과 달리, @CachePut은 항상 메서드를 실행하고 그 결과를 캐시에 업데이트한다.

@Service
public class ProductService {

    @Autowired
    private ProductRepository productRepository;

    /**
     * Write-Through 스타일: DB 저장과 동시에 캐시도 갱신함
     */
    @CachePut(value = "products", key = "#product.id")
    public Product updateProduct(Product product) {
        // 1. DB 업데이트 (메서드 본문 실행)
        Product updatedProduct = productRepository.save(product);
        
        // 2. 반환된 값이 설정된 key(#product.id)로 Redis에 자동 저장됨
        return updatedProduct; 
    }
}

3. Write-Through의 장단점: 백엔드 개발자의 트레이드오브

장점 (Pros)	단점 (Cons)
강력한 데이터 정합성: 캐시가 항상 최신 데이터를 가지고 있어 '데이터 불일치' 걱정이 거의 없습니다.	쓰기 지연(Latency): 매번 두 번의 쓰기 작업(Redis + DB)이 발생하므로 전체적인 서비스 속도가 느려질 수 있습니다.
읽기 성능 최적화: 데이터가 생성/수정될 때 이미 캐시에 들어있으므로, 첫 읽기 시 Cache Miss가 발생하지 않습니다.	리소스 낭비: 한 번 쓰고 다시는 읽지 않는 데이터까지 모두 캐시에 저장되어 메모리 공간을 차지합니다.

4. 실무에서는 언제 적용할까?

Write-Through는 모든 곳에 쓰기에는 비용이 크다. 따라서 다음과 같은 상황에서 잘 쓰인다.

• 데이터 정합성이 중요한 경우: 사용자 프로필 정보, 설정 값 등.
• 읽기 빈도가 압도적으로 높은 경우: 한 번 쓰고 나면 수만 번 읽히는 게시글이나 상품 상세 정보.
• 데이터 유실을 최소화해야 하는 경우.

만약 DB에는 저장했는데 Redis 저장에 실패한다면? 혹은 그 반대라면? 이처럼 분산 시스템에서의 트랜잭션 관리가 Write-Through의 가장 까다로운 문제이다. 보통은 DB 트랜잭션 내에 캐시 갱신 로직을 포함시켜 정합성을 맞춘다.