단기 데이터의 무덤: 일시적 작업 상태와 단기 캐시

상태(State)의 수명을 분류하라

서비스를 설계할 때 데이터의 수명을 명확히 분류하는 것은 매우 중요합니다. 영구적인 기록(결제 내역, 회원 정보)은 당연히 메인 데이터베이스로 가야 합니다.

하지만 어떤 데이터는 "지금 당장만 유효하고, 내일이면 아무도 찾지 않는 데이터"입니다. 비디오 인코딩 진행률, 대용량 엑셀 다운로드 준비 상태, 실시간 랭킹 집계 등이 여기에 속합니다.

무거운 쿼리를 막아주는 단기 캐시

진행 상태뿐만 아니라 "자주 바뀌지 않지만 계산하기 엄청나게 무거운 데이터"도 Redis의 훌륭한 타겟입니다.

예를 들어 쇼핑몰 메인 화면의 "지난 24시간 주간 베스트 상품 탑 10"을 생각해 봅시다. 이 데이터를 만들기 위해 수백만 건의 주문 테이블을 읽고 정렬해야 한다면 메인 DB는 비명을 지를 것입니다.

이런 데이터는 1분에 한 번만 계산해서 Redis에 넣어두고(단기 캐시), 모든 사용자는 Redis에서 완성된 데이터를 가져가게 만들면 부하를 획기적으로 줄일 수 있습니다.

async function getWeeklyBestProducts() {
  const CACHE_KEY = 'cache:weekly_best';
  
  // 1. 우선 Redis에 이미 계산된 결과가 있는지 확인합니다.
  const cachedData = await redis.get(CACHE_KEY);
  if (cachedData) {
    return JSON.parse(cachedData); // 있으면 바로 반환! (매우 빠름)
  }
  
  // 2. Redis에 없다면, 메인 DB에 엄청 무거운 쿼리를 날려 계산합니다.
  const products = await db.query(`SELECT ... FROM ... GROUP BY ...`);
  
  // 3. 계산된 결과를 Redis에 60초(1분) 동안만 저장합니다.
  await redis.set(CACHE_KEY, JSON.stringify(products), { EX: 60 });
  
  // 다음 1분 동안 이 함수를 호출하는 수만 명의 사용자는 1번 단계에서 바로 응답을 받습니다.
  return products;
}

일시적 캐시의 주의점: Cache Stampede (캐시 스탬피드)

단기 캐시 패턴은 훌륭하지만, 주의해야 할 함정이 있습니다. 인기 있는 데이터의 TTL(만료 시간)이 딱 끝나는 그 1초의 순간을 생각해 보세요.

Redis에서 데이터가 지워졌기 때문에, 그 순간 들어온 수천 명의 사용자 요청이 동시에 메인 DB로 무거운 쿼리를 날리게 됩니다. 이 현상을 캐시 스탬피드(Cache Stampede) 현상, 즉 들소 떼가 메인 DB를 짓밟는 현상이라고 부릅니다.

이를 방지하기 위해 데이터를 미리(만료되기 직전에) 백그라운드에서 갱신해 단두거나, 첫 번째 요청만 DB로 보내고 나머지는 잠시 대기시키는 등의 고급 전략을 실무에서는 사용하게 됩니다.