원본이 바뀌었을 때 캐시의 낡은 값을 없애거나 갱신하는 일.
"컴퓨터 과학에는 어려운 문제가 둘 있다 — 캐시 무효화와 이름 짓기." (필 칼튼) 농담이지만 실제로 분산 시스템에서 가장 까다로운 축에 속한다.
세 가지 방식
| 방식 | 내용 | 한계 |
|---|---|---|
| TTL 만료 | 시간이 지나면 자동 소멸 | TTL 동안은 낡은 값을 본다 |
| 명시적 삭제 | 갱신 시 관련 키를 지움 | 어떤 키가 영향받는지 다 알아야 한다 |
| 버전·태그 | 키에 버전을 넣고 버전을 올림 | 키 관리 부담 |
왜 어려운가 ① — 연관 키를 놓친다
상품 하나의 가격을 고쳤다고 하자. 지워야 할 캐시는 그 상품만이 아니다.
- product:100 — ← 상품 상세
- category:5:list — ← 그 상품이 속한 목록
- search:"노트북" — ← 검색 결과
- ranking:daily — ← 인기 순위
- cart:user:* — ← 장바구니에 담긴 사용자들의 합계 하나라도 빠뜨리면 화면마다 값이 달라진다. 이게 가장 흔한 사고다.
왜 어려운가 ② — 순서 경합
앞서 본 대로 "DB 갱신 → 캐시 삭제" 순서를 지켜도, 삭제 직전에 DB를 읽은 요청이 삭제 이후에 캐시를 채우면 낡은 값이 고착된다. 확률은 낮지만 0은 아니다.
왜 어려운가 ③ — 여러 인스턴스
로컬 캐시(애플리케이션 메모리)를 쓰면 서버가 10대일 때 10곳을 다 지워야 한다. Redis Pub/Sub이나 메시지 큐로 무효화 이벤트를 뿌려야 한다.
실무 전략
계층을 나눠 생각한다.
로컬 캐시(초 단위 TTL) ← 아주 짧게, 무효화 안 함
↓ 미스
Redis(분 단위 TTL + 명시적 삭제) ← 중요한 것만 삭제
↓ 미스
DB
로컬은 TTL만으로 관리하고(무효화 포기), Redis만 명시적으로 지운다. 이러면 관리 지점이 하나로 줄어든다.
면접 답변 골격
"완벽한 무효화는 어렵다고 전제합니다. 짧은 TTL을 기본 안전망으로 깔고, 사용자가 자기 변경을 즉시 봐야 하는 화면만 명시적으로 지웁니다. 나머지는 최종 일관성을 허용하는 쪽으로 설계합니다."