캐시를 지우는 일이 어려운 이유는?

원본을 바꾸는 작업과 캐시를 고치는 작업이 서로 다른 실패 단위를 갖기 때문이다. 데이터베이스 반영은 성공했는데 캐시 삭제가 실패하면 이전 값이 남는다.

경쟁도 생긴다. 한 요청이 이전 값을 읽은 직후 다른 요청이 원본을 바꾸고 캐시를 지울 수 있다. 첫 요청이 뒤늦게 이전 값을 캐시에 채우면 삭제가 성공했어도 다시 낡아진다. 버전 비교나 조건부 쓰기로 오래된 채우기를 막아야 한다.

무엇을 지울지도 단순하지 않다. 상품 하나가 바뀌면 상품 키뿐 아니라 목록·검색 결과·집계가 함께 낡을 수 있다. 키와 의존 관계가 코드에 흩어지면 일부를 빠뜨린다.

먼저 업무가 허용하는 오래된 값의 시간을 정한다. TTL은 그 시간을 넘기지 않는 안전망이다. 쓰기 이벤트로 빨리 지우더라도 전달 실패를 재처리한다. 같은 시각에 많은 키가 만료되지 않도록 jitter를 주고 같은 키의 동시 재조회는 하나로 합친다.

캐시 장애나 전체 비우기 때 원본으로 요청이 쏟아지는 경로도 부하 시험한다. 캐시는 성능을 돕는 계층이지 원본을 쓰러뜨리는 단일 실패점이 되어서는 안 된다.