캐시가 만료돼도 옛 값을 먼저 주고 뒤에서 갱신하려 합니다. stale-while-revalidate는 어떤 데이터에 적합한가요?

잠시 오래된 결과를 허용하는 조회에서 응답 지연과 원본 burst를 줄이는 방식입니다. 신선한 기간과 오래된 값을 허용할 최대 기간을 구분하고 갱신 실패 때 무한히 stale을 주지 않아야 합니다.

동작 원리와 전제

상품 설명은 이전 값을 보여 줄 수 있지만 권한 회수·재고 확정·결제 결과는 잘못된 결정 비용이 큽니다. 표시용 stale 조회와 실제 변경의 권위 검증을 분리합니다. 갱신 작업은 같은 키에서 합치고 시간·동시성 상한을 둡니다.

선택과 실패 처리

갱신 실패와 데이터 삭제를 같은 것으로 처리하지 않습니다. 오래된 버전의 느린 refill이 새 값을 덮지 않게 버전 조건을 사용합니다. HTTP 캐시 지시문과 앱 내부 구현은 지원·오류 동작이 다를 수 있어 실제 계층을 확인합니다.

구체적인 사례와 검증

신선도 1분과 stale 허용 5분을 정했다면 원본 장애가 한 시간 이어져도 무한히 같은 값을 주면 계약을 어깁니다. 최대 나이를 넘으면 명시적인 실패·기능 축소·원본 조회 정책을 사용합니다. 삭제된 상품이나 회수된 권한은 단순 낡은 설명과 오류 비용이 달라야 합니다. 공유 refresh의 첫 요청이 취소됐다고 다른 대기자의 갱신까지 무조건 취소할지 수명을 정하고, 모든 대기자가 사라지면 계속할 필요가 있는지도 판단합니다. refresh 결과가 현재 캐시 버전보다 낮으면 저장하지 않게 하며, 갱신 성공률과 실제 stale 나이를 함께 봅니다.

만료 집중·원본 장애·삭제·권한 변경·갱신 취소를 시험합니다. stale 응답 비율·최대 나이·갱신 성공·원본 호출량을 관찰합니다. 사용자에게 필요한 최신성 계약을 명시한 뒤 지연 이점을 평가하겠습니다.