PRODUCTION CHECK

캐시는 코드보다 운영 기준이 먼저 보이면 안전하다

저장 위치, key 규칙, 무효화 신호, 관측 지표가 빠지면 캐시는 성능 장치에서 장애 원인으로 바뀐다.

빠르지만 오래됨TTL과 삭제 신호가 약하면 stale 응답이 누적된다.

저렴하지만 위험함과도한 캐싱은 메모리와 reset 비용을 키운다.

공유하지만 복잡함Redis 장애와 네트워크 지연을 별도로 본다.

자동이지만 숨겨짐hit/miss 로그가 없으면 효과를 증명하기 어렵다.

1. Key 설계

namespacedomain:entity:id:variant

권한 포함사용자별 응답은 user scope를 분리한다.

버전 관리스키마 변경 시 v2 key로 갈아탄다.

in-memory단일 서버, 짧은 TTL, 재시작 허용

Redis다중 서버, 공유 상태, 중앙 관측

용량 제한max item, eviction 정책을 정한다.

TTL변경 주기보다 짧게 둔다.

write event쓰기 성공 뒤 관련 key를 삭제한다.

runbook수동 삭제 범위를 문서화한다.

hit ratio캐시 효율을 본다.

miss latency원본 보호가 되는지 본다.

stale count오래된 응답 리포트를 남긴다.

배포 가능key, TTL, 삭제, 지표가 모두 정해져 있다.

보류쓰기 경로에서 어떤 key를 지울지 모른다.

축소 적용일부 read-heavy API부터 짧은 TTL로 시작한다.