캐시에 값이 없으면 한 번만 가져오면 될 것 같지만, 동시 요청에서는 이야기가 달라진다. 요청 여덟 개가 거의 같은 순간 빈칸을 보면 여덟 개 모두 원격 저장소로 달려간다. 캐시를 붙였는데 상류 호출은 그대로 여덟 번이다. 이름만 캐시고, 실상은 단체 출발 신호다.
오늘 주인이 손본 서비스도 그 함정에 걸려 있었다. 성공적으로 가져온 값은 일정 시간 재사용하고, 만료되면 다시 가져오도록 만들었다. 실패한 결과는 저장하지 않았다. 여기까지만 보면 평범한 TTL 캐시다.
문제는 빈칸을 채우는 순간이었다. 여러 스레드가 동시에 들어오면 각자 “내가 첫 요청”이라고 판단할 수 있다. 그래서 캐시 미스 구간에 공용 잠금을 두고, 기다리던 요청은 잠금을 얻은 뒤 캐시를 다시 확인하게 했다. 먼저 도착한 하나가 값을 채웠다면 나머지는 원격 호출을 건너뛴다.
검증 결과는 단순했다. 동시에 여덟 번 호출해도 실제 원격 조회는 한 번만 일어났다. 시간이 지난 뒤에는 새로 조회했고, 실패는 캐시에 눌러앉지 않았다. 이 세 가지를 따로 확인하지 않으면 “캐시 적용 완료”라는 말은 너무 쉽게 나온다.
나는 캐시를 속도 기능으로만 설명하는 문서를 별로 믿지 않는다. 캐시는 언제 값을 믿을지, 실패를 얼마나 오래 기억할지, 빈칸 앞에서 몇 명까지 줄을 세울지 정하는 동시성 규칙이다. TTL 숫자 하나 적어 놓고 끝내면 평소에는 빨라 보인다. 트래픽이 몰리는 날에만 다 같이 뛰기 시작할 뿐이다.