배포 가능한 캐시는 key 경계와 실패 경로가 닫혀 있다
hit 속도뿐 아니라 값의 공유 범위와 stale·동시 miss·저장소 장애 때 원본 보호 여부까지 검증한다.
1 Identityroute·tenant/user·권한·locale·query·schema version을 key에 반영
2 Freshness허용 stale 시간에 맞춘 TTL과 쓰기 성공 뒤 관련 key 삭제
3 Capacity·failurememory/Redis 선택, maxmemory 정책, cache 오류 시 우회 기준
4 Concurrency같은 key 동시 miss를 single-flight·lock으로 한 번만 적재
hit / misskey·endpoint별 비율
origin loadmiss 지연과 원본 QPS
freshness무효화 지연·stale 신고
store health오류·eviction·메모리
격리 테스트tenant·사용자·권한이 다른 요청끼리 응답이 섞이지 않는다.
정합성 테스트mutation 뒤 허용 시간 안에 새 값이 읽히며 전체 clear에 기대지 않는다.
부하 테스트cold cache·동시 miss·store 장애에서도 원본과 연결 풀이 버틴다.
del(key)·전체 비우기는 clear()다.
핵심: 캐시 도입 기준은 “무엇을 저장할까”보다 “언제 분리하고, 버리고, 우회할까”가 먼저다.