네 설계 의도 감사합니다. ㅎ
모든 원격 호출을 로컬 디스크 쓰기로 저장하다가, 원격 호출이 실패할때는 디스크 읽기를 한다는 말씀이시죠? 캐시레이어에 Disk가 꼭 필요한지도 고민해보시면 좋을 것 같습니다.
DiskLayer는 그런 패턴이 아니라 그냥 일반 캐시 레이어로 동작합니다 — 읽기도 하고 쓰기도 하고, 위 레이어 미스나면 순서대로 접근하는 구조예요. 혼선을 드렸네요.
말씀하신 "원격 호출 결과를 디스크에 저장했다가 실패 시 읽는" 패턴은 사실 stale-if-error 옵션이 더 가깝긴 한데, 그건 메모리에 들고 있는 거라 프로세스 재시작하면 날아가요.
그리고 DiskLayer가 꼭 필요하냐는 지적은 음. 실제로 대부분의 다중 인스턴스 환경에서는 Memory → Redis만으로 충분하고, Disk가 레이어로 들어오는 순간 직렬화 비용이나 파일 관리 복잡도가 따라오거든요.
Redis가 들어간 건 서버가 여러 대일 때를 가정해서예요. 각 서버의 메모리는 서로 다른 값을 갖고 있을 수 있으니까, Redis가 "공유 진실" 역할을 합니다.
Disk가 Redis보다 뒤에 오는 건 Redis가 같은 로컬 네트워크에 있다는 가정 하에 더 빠르기 때문이에요. 벤치마크 기준으로 Disk는 ~2ms, Redis는 ~0.02ms거든요. 하지만 Redis가 멀리 있거나 네트워크가 나쁘면 로컬 Disk가 더 빠를 수 있고, 그럴 땐 순서를 바꾸는 게 맞아요. 라이브러리도 순서를 강제하지 않고 사용자가 직접 정하는 구조입니다.
Disk는 어디에 있든 간에 속도 경쟁보다는, Memory와 Redis가 다 죽었을 때 살아남는 마지막 보험 역할이 주목적이에요.