Cache 전략과 정합성

Cache는 응답 시간을 낮추고 DB 부하를 줄이지만, 동시에 오래된 값과 무효화 실패라는 새 문제를 만든다.
좋은 캐시 설계는 “무엇을 캐시할까?”보다 “얼마나 오래 틀려도 되는가?”, “틀렸을 때 사용자는 무엇을 보는가?”, “원본 데이터 변경을 어떻게 전파할 것인가?”를 먼저 묻는다.
Java/Spring 백엔드에서는 Redis, local cache, DB, event, API 계약이 함께 움직이므로 성능, 정합성, 장애 격리, 운영 복잡도를 같이 판단해야 한다.

Cache Aside는 애플리케이션이 cache miss와 cache fill을 직접 관리한다. 단순하지만 miss 폭주, stale data, 예외 처리 책임도 애플리케이션에 있다.
Read Through와 Write Through는 캐시 계층이 읽기/쓰기 흐름에 더 깊게 들어온다. 애플리케이션 코드는 단순해질 수 있지만 캐시 인프라 의존성과 write latency가 커질 수 있다.
TTL은 “언젠가 지워지는 시간”이 아니라 사용자가 오래된 값을 볼 수 있는 최대 시간에 가깝다. 가격, 재고, 권한처럼 피해가 큰 값은 TTL만으로 부족할 수 있다.
Invalidation은 정합성을 개선하지만 이벤트 유실, 순서 역전, 중복 처리, 배포 중 호환성 같은 운영 문제를 만든다.
Cache Stampede는 같은 key가 동시에 만료되어 DB로 요청이 몰리는 문제이고, Hot Key는 특정 key 하나가 Redis나 네트워크를 과열시키는 문제다.
캐시 정합성 문제는 DB 내부 문제가 아니라 사용자 경험 문제다. 방금 수정한 값이 화면에 안 보이는지, 결제 후 주문 상태가 늦게 바뀌는지, 재고가 잘못 보이는지로 설명해야 한다.
개인 프로젝트에서는 cache key, TTL, 캐시 대상, 원본 DB fallback, 장애 시 동작을 문서화하면 충분히 수준이 올라간다.
기업 운영에서는 hit ratio, stale read, Redis CPU, memory, eviction, hot key, invalidation 실패, fallback rate를 지표로 본다.

01. Cache Aside Read Through Write Through 상세.md는 캐시 읽기/쓰기 패턴이 코드 책임과 정합성 책임을 어떻게 바꾸는지 다룬다.
02. TTL Eviction Invalidation 상세.md는 만료, 제거, 무효화가 사용자에게 보이는 오래된 값의 시간을 어떻게 결정하는지 다룬다.
03. Cache Stampede와 Hot Key 상세.md는 캐시가 오히려 DB와 Redis에 순간 부하를 만드는 상황과 방어 전략을 다룬다.
04. 정합성 깨짐과 사용자 경험 상세.md는 stale data를 기술 문제가 아니라 사용자 경험과 API 계약 문제로 다룬다.
05. Redis Cache 실전 설계 상세.md는 key 설계, TTL, serializer, 메모리 추정, 장애 fallback, 운영 지표를 실제 설계 형태로 정리한다.

캐시를 넣으면 항상 더 안정적이라고 생각하기 쉽다. DB 부하가 줄어드는 효과가 먼저 보이기 때문이다.
- 핵심은 캐시가 DB 부하를 낮추는 대신 stale data, invalidation 실패, Redis 장애라는 새 실패 모드를 만든다는 점이다.
- 캐시 도입은 성능 최적화이면서 정합성 모델 변경이다.
TTL을 짧게 잡으면 정합성 문제가 해결된다고 생각하기 쉽다. 오래된 값이 빨리 사라질 것처럼 보이기 때문이다.
- 핵심은 짧은 TTL이 miss 증가와 stampede를 만들 수 있다는 점이다.
- TTL은 정합성, DB 부하, Redis 부하 사이의 타협값이다.
Redis를 쓰면 DB 장애를 대부분 막을 수 있다고 오해하기 쉽다. 캐시 hit 동안 DB를 덜 쓰기 때문이다.
- 핵심은 cache miss, cold start, invalidation, Redis 장애 시 결국 DB와 애플리케이션이 버텨야 한다는 점이다.

확인 질문: 캐시 도입 전에 가장 먼저 물어야 하는 질문은 무엇인가?
- 답변: 캐시된 값이 얼마나 오래 틀려도 되는지, 틀렸을 때 사용자가 어떤 피해를 보는지, 원본 변경을 어떻게 반영할지다.
확인 질문: TTL만으로 부족한 데이터는 어떤 데이터인가?
- 답변: 가격, 재고, 권한, 결제 상태처럼 오래된 값이 사용자 손해나 보안 문제로 이어질 수 있는 데이터다.
확인 질문: 캐시 설계에서 운영 지표가 필요한 이유는 무엇인가?
- 답변: hit ratio만으로는 충분하지 않고 Redis CPU, memory, eviction, stale read, fallback, hot key를 봐야 실제 효과와 위험을 알 수 있기 때문이다.

동블