Write-Back 전략

Write-Back은 모든 쓰기 작업을 캐시(Redis)에 먼저 하고, 일정 시간이나 일정 데이터 양이 쌓인 뒤에 비동기적으로 DB에 반영하는 방식이다. “일단 캐시에 적어두고 나중에 한 번에 DB에 정리하자”는 개념이다.

1. 동작 흐름

1. Write Request: 데이터 저장/수정 요청이 들어온다.
2. Cache Write: Redis에 즉시 데이터를 쓴다 (여기서 클라이언트에게 응답을 보낸다)
3. Buffuring: 데이터가 Redis에 일시적으로 머문다.
4. Batch Update: 특정 주기 혹은 특정 개수가 모이면 DB에 벌크(Bulk)로 업데이트한다.

2. 실무 적용 예시: 좋아요 수 카운팅

Spring Boot에서 이 방식을 구현하려면 단순히 어노테이션만으로는 부족하며 스케줄러(@Scheduled)나 메시지 큐를 조합해야 한다.

@Service
public class LikeService {

    @Autowired
    private RedisTemplate<String, String> redisTemplate;

    @Autowired
    private PostRepository postRepository;

    // 1. 사용자가 좋아요를 누르면 Redis 카운트만 올림 (매우 빠름)
    public void addLike(Long postId) {
        redisTemplate.opsForValue().increment("post:like:" + postId);
    }

    // 2. 10분마다 실행되는 스케줄러가 Redis의 데이터를 DB에 한꺼번에 반영
    @Scheduled(fixedDelay = 600000) 
    public void syncLikesToDB() {
        // Redis에서 모든 좋아요 키를 가져와서 DB에 Batch Update 수행
        // (실제로는 더 복잡한 배치 로직이 들어갑니다)
        System.out.println("Redis 데이터를 DB로 일괄 전송 중...");
    }
}

3. 장단점

장점 (Pros)	단점 (Cons)
압도적인 쓰기 성능: DB I/O 부하를 획기적으로 줄여줍니다. 쓰기 요청이 폭주해도 서비스가 거뜬합니다.	데이터 유실 위험: DB에 쓰기 전에 Redis 장애가 발생하면 메모리에만 있던 데이터는 영구 삭제됩니다.
DB 부하 감소: 매번 쿼리를 날리는 대신 한꺼번에 모아서 처리하므로 DB 자원을 아낄 수 있습니다.	구현 복잡도: 캐시와 DB 사이의 동기화 로직을 직접 짜야 하며, 실패 시 재시도(Retry) 처리도 필요합니다.

4. 언제 써야할까?

Write-Back은 약간의 데이터 유실은 감수할 수 있지만 성능이 생명인 곳에 적합하다.

• 동영상 조회 수 / 게시글 좋아요 수: 100만명의 조회수를 실시간으로 DB에 1씩 더하면 DB는 죽는다.
• 게임 로그 / 스트리밍 지표: 실시간성이 중요하고 데이터 양이 방대한 경우
• 실시간 채팅 메시지: 메시지를 Redis에 먼저 쌓아두고 나중에 히스토리 DB로 넘길 때 사용한다.

5. 장애 대비책

만약 Redis가 죽으면 데이터가 날아가는 게 싫다면 Redis의 백업 기능을 활성화하거나 Redisㅇ 대신 유실 방지 기능이 더 강력한 메시지 큐를 중간에 두는 방식으로 보완한다.