캐시 무효화는 빠른 값을 저장하는 문제가 아니라 낡은 값을 버리는 문제입니다

캐시는 읽기를 빠르게 하지만, 정답이 바뀌는 순간부터 무효화 규칙이 본체가 됩니다.

느린 API 앞에 캐시를 붙이면 응답이 빨라집니다.
DB 부하도 줄고, 화면도 빨리 뜹니다.
여기까지는 쉽습니다.
진짜 문제는 원본 값이 바뀐 뒤에 시작합니다.
캐시는 빠른 값이 아니라 “언제까지 믿어도 되는 값”입니다.

TTL은 정답이 아니라 타협입니다

TTL을 5분으로 두면 최대 5분 동안 낡은 값을 보여줄 수 있습니다.
5초로 줄이면 부하는 다시 늘어납니다.
그래서 TTL은 기술값이 아니라 제품 판단입니다.
가격, 권한, 결제 상태처럼 틀리면 위험한 값은 짧게 두거나 명시적으로 지워야 합니다.
추천 목록이나 인기 글 순위처럼 조금 늦어도 되는 값은 길게 둘 수 있습니다.

무효화 경로가 없으면 캐시는 복사본이 됩니다

원본이 바뀔 때 관련 캐시를 지우는 경로가 있어야 합니다.
사용자 프로필이 바뀌면 프로필 캐시만 지울지, 사용자 요약 카드까지 지울지 정해야 합니다.
이 관계를 코드 안에 흩뿌리면 나중에 찾기 어렵습니다.
캐시 키 규칙과 무효화 규칙을 같이 두는 편이 유지보수에 낫습니다.

낡아도 되는 시간을 문장으로 씁니다

캐시 설계에서 제가 먼저 쓰는 문장은 이겁니다.
“이 값은 최대 몇 초까지 낡아도 되는가.” 이 문장을 못 쓰면 캐시를 붙이기 이릅니다.
빠르게 만드는 일보다, 틀린 값을 얼마나 오래 보여줄지 정하는 일이 먼저입니다.

마지막으로 확인할 것은 하나입니다.
이 개념을 외웠는지가 아니라, 실패했을 때 어떤 상태가 남는지 설명할 수 있는지입니다.