요청 조건, 사용자 범위, 버전을 같은 이름 규칙에 넣습니다.
캐시는 key, TTL, 무효화, 장애 대응을 같이 설계한다
저장소를 고르기 전에 같은 요청을 어떻게 이름 붙이고, 얼마나 오래 믿고, 언제 지우며, 미스가 몰릴 때 어떻게 버틸지 정합니다.
데이터 변경 주기보다 짧게 시작하고 hit ratio로 보정합니다.
쓰기 성공 뒤 어떤 key를 지울지 로그로 추적 가능해야 합니다.
miss 폭주, 원본 장애, stale 응답 허용선을 먼저 정합니다.
| 항목 | 결정 질문 | 나빠지는 신호 | 운영 기준 |
|---|---|---|---|
| KEY | 같은 요청이 항상 같은 이름인가 | 권한·버전이 섞여 잘못된 값 반환 | scope와 version을 key에 포함 |
| TTL | 변경 주기보다 짧은가 | stale window가 업무 허용치를 넘음 | 짧은 TTL에서 시작해 보정 |
| DEL | 쓰기 후 관련 key를 찾을 수 있는가 | 수정 직후 예전 값이 계속 보임 | 무효화 이벤트와 재시도 로그 |
| SAFE | miss 폭주와 원본 장애를 막는가 | miss latency와 DB pool wait 증가 | single flight, rate limit, stale 허용선 |
핵심: 자주 읽고 덜 바뀌면 TTL 후보, 자주 바뀌거나 중요하면 무효화 이벤트와 짧은 TTL을 함께 둔다.