데이터베이스를 수정한 뒤 캐시를 삭제하면 오래된 값이 다시 캐시에 들어갈 가능성은 없나요?

캐시 어사이드는 캐시 miss 때 애플리케이션이 DB에서 읽어 캐시를 채우는 방식입니다. 쓰기 때 DB를 갱신한 뒤 캐시를 삭제할 수 있지만, 그것만으로 오래된 값의 재삽입을 막지는 못합니다. 읽기 요청이 먼저 DB에서 옛 값을 읽고 잠든 사이 쓰기 요청이 새 값을 커밋하고 캐시를 지울 수 있습니다. 그 뒤 잠자던 읽기가 옛 값을 캐시에 넣으면 삭제가 성공했어도 캐시가 다시 낡습니다. 따라서 무효화 성공과 진행 중 읽기의 수명을 별도로 봐야 합니다.

읽기와 쓰기의 경합

전형적인 순서는 read: miss → DB(old) → pause, write: DB(new) → delete, read: set(old)입니다. 읽기가 DB를 조회한 시각에는 옛 값이 맞았지만 캐시에 저장하는 시각에는 최신이 아닙니다. 이를 오래된 값의 지연 채우기(stale refill)라고 부릅니다. 읽기와 삭제 순서를 바꾸는 것만으로 해결된다고 하지 않고, 읽기·쓰기·무효화의 원자 경계를 확인하겠습니다.

변경 때마다 증가하는 버전을 DB에서 읽어 캐시에 같이 저장하면 낮은 버전의 채우기를 거절할 수 있습니다. 버전 12를 관찰한 뒤 11을 넣으려 하면 거절하는 식입니다. 그러나 비교와 저장은 원자적이어야 하고 eviction으로 최소 버전 장벽까지 사라지면 옛 채우기가 다시 허용될 수 있습니다. 삭제된 값과 버전 기준의 수명을 별도로 관리해야 합니다.

허용할 불일치와 권위 지점

상품 설명·추천처럼 잠시 오래된 화면을 허용하면 TTL, 무효화 재시도, stale-while-revalidate로 복잡도를 낮출 수 있습니다. TTL은 현재 캐시 값의 수명이지 DB 변경 후 최신화의 기한이 아닙니다. 느린 읽기·복제본 지연·무효화 유실이 있으면 그 약속을 깨뜨립니다.

재고·권한·중복 결제처럼 잘못된 판단의 비용이 큰 작업은 캐시를 최종 권위로 쓰지 않겠습니다. 화면은 캐시에서 읽더라도 실제 변경 시 DB의 버전·잔량을 조건부 갱신으로 재확인합니다. outbox나 CDC로 무효화를 보강해도 진행 중 옛 읽기의 refill은 남으므로 버전 장벽이나 읽기 제한이 필요합니다.

검증에서는 DB 조회 후 읽기를 멈추고 쓰기·삭제를 먼저 한 뒤 읽기를 재개합니다. 캐시와 원본의 버전 차이, 무효화 지연, stale 응답, 캐시 장애 때 원본 호출량을 봅니다. 모든 캐시를 강하게 만들기보다 오래된 조회와 강한 결정을 분리하고 계약을 명시하는 것이 결론입니다.

버전 장벽을 유지하는 방법

캐시 값을 삭제할 때 최신 버전 12라는 작은 표식을 남기고, 채우기 요청은 자신이 DB에서 읽은 버전과 함께 값을 제출하게 할 수 있습니다. 저장소가 한 원자 연산에서 표식보다 낮은 버전을 거절해야 합니다. 애플리케이션에서 GET으로 버전을 검사한 뒤 SET하면 그 사이 새 쓰기가 들어오는 경쟁이 다시 생깁니다. 표식도 캐시 용량 정책으로 제거될 수 있으므로 진행 중 읽기의 최대 수명보다 오래 보존하거나 별도 권위 있는 버전 경로를 사용해야 합니다.

쓰기가 성공한 사용자에게 새 값을 보여 주는 요구는 전체 독자의 강한 일관성과 다릅니다. 저장 응답의 값을 즉시 화면에 표시하고 해당 세션의 최소 읽기 버전을 유지하면 본인 쓰기 관찰을 개선할 수 있습니다. 다만 다른 사용자의 최신 쓰기까지 보장하지는 않습니다. 삭제 이벤트만 여러 번 재시도하는 방법과 버전 기반 저장을 비교할 때는 캐시 장애 시 원본으로 우회하는 부하, 표식 보관 비용, 읽기 지연을 함께 보겠습니다.