캐시와 반정규화

같은 조회 요구라도 이름 변경 비용을 어디에 두는지가 다릅니다

상품 목록에 카테고리명을 보여줘야 할 때, DB에 값을 복제하면 조회는 단순해지지만 변경이 무거워지고, Redis 캐시는 정규화를 유지한 채 조회 시 조합하도록 바꿉니다.

공유 전제
화면은 상품 + 카테고리명을 원하지만, 원본 데이터는 정규화된 상태로 시작합니다.
products id, name, category_id
categories id, name
목록 화면 상품명 옆에 카테고리명 표시
DB 반정규화
Redis 캐시
저장 위치 이름을 어디에 두나
products에 category_name을 함께 저장
products(id, name, category_id, category_name)

조회 시 조인 없이 바로 읽을 수 있지만, 같은 이름이 여러 상품 행에 중복됩니다.

카테고리명은 Redis 키로 따로 캐시
category:1 -> "전자제품" category:2 -> "의류"

DB는 category_id만 유지하고, 조회 시 캐시에서 이름을 붙입니다.

이름 변경 상태 변화가 생기면
카테고리명 수정이 여러 상품 UPDATE로 번짐
UPDATE categories SET name = '디지털'; UPDATE products SET category_name = '디지털' WHERE category_id = 1;

읽기 편의를 위해 만든 복제 값이 쓰기 비용과 일관성 관리 부담으로 돌아옵니다.

원본은 그대로 두고 캐시만 갱신하거나 제거
UPDATE categories SET name = '디지털'; DEL category:1 // 또는 SET category:1 "디지털"

변경 전파 범위가 캐시 키 단위로 좁아져 정규화를 유지한 채 운영하기 쉽습니다.

운영 의미 무엇이 달라지나
조회 단순성은 얻지만 데이터 복제가 남습니다

카테고리 이름이 바뀔수록 중복 데이터와 대량 UPDATE 비용이 눈에 띄게 커집니다.

정규화 유지가 쉬워지지만 캐시 장애 대비가 필요합니다

캐시 미스, 재구성, 장애 시 DB fallback 같은 운영 전략을 함께 준비해야 합니다.

핵심: Redis 캐시는 “카테고리명을 어디에 복제할까”를 “조회 시 어떤 키를 조합할까”로 바꿔서, 정규화는 유지하고 변경 비용은 캐시 무효화 문제로 옮깁니다.