캐시를 단순 성능 도구로만 보는지, 아니면 읽기·쓰기 경로와 정합성 트레이드오프까지 정해진 기준으로 풀 수 있는지를 가른다.
Cache Aside는 읽기 시 캐시 미스가 나면 원본 DB에서 가져와 캐시에 적재하는 가장 흔한 패턴이다 — "실제로 읽히는 데이터만" 캐시에 남는다. 쓰기 쪽은 보통 세 가지 중 고른다. Write Through는 캐시와 원본을 동시에 갱신해 정합성을 가장 강하게 가져가지만 쓰기 지연이 늘어난다. Cache Invalidation은 쓰기 시 캐시를 지우고 다음 읽기에서 다시 채우게 한다 — 단순하지만 캐시 미스 폭증과 동시성 경합이 따라온다. Write Behind는 캐시를 먼저 쓰고 원본 반영을 비동기로 미뤄 쓰기 처리량을 끌어올리지만 장애 시 데이터 유실 위험이 생긴다. 즉 캐시 설계는 "정합성·지연·비용" 중 무엇을 어느 데이터에서 양보할지 정하는 일이다.
캐시 도입 전후 p95 응답 시간과 DB QPS 변화를 수치로 본 경험이 있다면 "전략 선택이 정량적으로 다른 결과를 낸다"는 근거로 풀어낼 수 있다
캐시 정합성 사고(옛 값이 노출되거나 stale write로 덮어써짐)를 추적해 본 경험이 있다면 무효화 정책 선택의 사례로 보여 줄 수 있다
캐시 키 설계·TTL·무효화 시그널을 다시 잡아 본 경험이 있다면 "캐시는 키 설계가 절반"이라는 관점으로 일반화할 수 있다
Write Behind를 도입했다가 장애 직전 미반영 쓰기를 복구해야 했던 경험이 있다면 비동기 전략의 리스크 이야기로 이어갈 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.