결정: 어떤 캐싱 전략인가?

캐시는 자주 읽는 데이터를 데이터베이스 앞단의 빠른 계층(예: Redis)에 유지해 지연과 DB 부하를 낮춘다. 그러나 모든 데이터가 캐싱에 적합한 것은 아니며, 잘못된 무효화는 오래된/잘못된 데이터의 위험을 만든다. 이 트리는 먼저 캐시가 정말 필요한지 확인하고, 읽기/쓰기 패턴에 따라 cache-aside, read-through, write-through, write-behind 중 선택을 도우며, stampede 방지도 다룬다.

워크로드는 어떤 형태인가: 읽기 중심인가, 쓰기 중심인가?

캐시는 같은 데이터를 여러 번 읽고(읽기 중심) 자주 변경되지 않을 때 가장 효과가 크다. 먼저 전체 패턴을 파악한다: 데이터를 많이 읽고 드물게 변경하는가, 계속 갱신하는가, 아니면 캐시를 추가할 가치가 있는지 확실하지 않은가?

• 매우 읽기 중심, 데이터 변경은 비교적 드묾
• 쓰기도 많음, 쓴 데이터를 즉시/자주 읽음
• 확실하지 않음, 캐시가 정말 필요한가?

캐시 채우기는 누가 담당해야 하는가?

읽기 중심 시나리오에서 핵심 선택은 누가 캐시를 채우는가이다. 애플리케이션이 캐시를 명시적으로 관리하고 직접 DB로 폴백해야 하는가(높은 유연성), 아니면 캐시 계층이 miss 시 백엔드 DB에서 데이터를 가져와 투명하게 반환해야 하는가?

• 애플리케이션이 명시적으로 관리, 유연성과 통제를 원함
• 캐시 계층이 miss 시 DB에서 가져옴(투명)

쓰기 시 일관성과 쓰기 속도 중 무엇이 우선인가?

쓰기가 많다면 쓴 데이터가 캐시와 DB 간에 얼마나 일관될지 결정해야 한다. 일관성을 보장하기 위해 모든 쓰기에서 캐시와 DB를 함께 갱신해야 하는가(쓰기가 다소 느림), 아니면 쓰기를 먼저 캐시에 보내고 백그라운드에서 비동기로 DB에 반영해야 하는가(쓰기는 매우 빠르지만 손실 위험)?

• 일관성이 중요, 읽기는 항상 최신이어야 함
• 쓰기 속도가 핵심, 약간 지연된 일관성과 손실 위험은 허용

권장: 지금은 캐시를 추가하지 않는다

캐시는 공짜가 아니다: 일관성 문제(오래된 데이터), 추가 인프라, 무효화 복잡성을 가져온다. 쿼리가 이미 빠르거나 요청마다 데이터가 바뀐다면 캐시는 이점 없이 장애 지점만 늘린다.

권장: cache-aside(lazy loading)

cache-aside에서는 애플리케이션이 먼저 캐시를 확인한다. 데이터가 없으면(miss) DB에서 읽어 캐시에 쓰고 반환한다. 가장 일반적이고 유연한 패턴이며, 실제로 요청된 데이터만 캐시에 채워진다.

권장: read-through 캐시

read-through에서는 애플리케이션이 캐시와만 통신한다. miss 시 캐시 계층이 직접 DB에서 데이터를 가져와 채운다(provider/loader를 통해). 애플리케이션 코드가 단순해지고 채우기 로직이 한곳에 모인다.

권장: write-through 캐시

write-through에서는 모든 쓰기가 캐시와 DB 양쪽에(동기적으로) 기록되어 둘이 함께 갱신된다. 따라서 캐시가 DB보다 뒤처지지 않고 읽기는 항상 최신 데이터를 본다.

권장: write-behind(write-back) 캐시

write-behind에서는 쓰기가 먼저 캐시로 가고 사용자에게 즉시 반환된다. DB 쓰기는 백그라운드에서 비동기로(배치/지연) 수행된다. 쓰기 속도는 가장 빠르지만 내구성과 일관성 위험이 따른다.