Write-Around 전략

데이터를 저장하거나 수정할 때 캐시(Redis)에는 아무런 작업을 하지 않고, 오직 데이터베이스에만 기록하는 방식이다.

캐시는 오직 읽기 요청이 발생했을 때만 채워지게 된다.

동작 흐름

1. Write Request: 데이터 생성 또는 수정 요청이 들어온다.
2. DB Update: 오직 DB에만 데이터를 저장한다 (Redis는 건드리지 않는다)
3. Read Request: 해당 데이터를 읽으려 할 때 Redis에 데이터가 없으므로 Cache Miss가 발생한다.
4. Cache Fill: DB에서 데이터를 읽어와서 Redis에 저장한다 (이후에는 Cache Hit)

Spring Boot 코드 예시

Spring에서는 별도의 캐시 없데이트 어노테이션(@CachePut)을 쓰지 않거나 데이터 수정 시 기존 캐시를 삭제해버리는 @CacheEvict와 조합하여 사용한다.

@Service
public class PostService {

    @Autowired
    private PostRepository postRepository;

    /**
     * Write-Around 스타일: DB에만 저장함. 
     * 캐시 관련 어노테이션이 없으므로 Redis는 건드리지 않음.
     */
    public Post savePost(Post post) {
        return postRepository.save(post);
    }

    /**
     * 읽기 시점에 캐시가 채워짐 (Cache-Aside와 찰떡궁합)
     */
    @Cacheable(value = "posts", key = "#id")
    public Post getPost(Long id) {
        return postRepository.findById(id).orElseThrow();
    }
}

Write-Around의 장단점

장점 (Pros)	단점 (Cons)
쓰기 성능 최적화: Redis를 업데이트하는 부하가 없으므로 쓰기 속도가 매우 빠릅니다.	첫 읽기 지연: 데이터 수정 후 첫 번째 조회는 무조건 DB를 거쳐야 하므로 느립니다.
캐시 효율성: 한 번도 읽히지 않을 데이터가 캐시 메모리를 차지하는 낭비를 막을 수 있습니다.	데이터 정합성 주의: DB 데이터가 수정되었는데 캐시에 과거 데이터가 남아있다면? (반드시 캐시 삭제 로직이 필요함)

백엔드 개발자의 실무 포인트

Write-Around를 사용할 때 가장 주의해야 할 점은 데이터 수정 시 기존에 있던 캐시를 어떻게 할 것인가이다.

DB만 업데이트하고 기존 캐시를 그대로 두면 사용자는 한동안 옛날 데이터를 보게 된다.

이때 가장 많이 사용하는 방법이 @CacheEvict(캐시 삭제)이다.

@CacheEvict(value = "posts", key = "#post.id") // 수정 시 기존 캐시를 삭제
public Post updatePost(Post post) {
    return postRepository.save(post);
}

이렇게 하면 다음 읽기 요청 때 새로운 데이터를 DB에서 읽어와 캐시를 최신화하게 된다.