8.5 KiB
title, source_type, url, archive_url, status, confidence, tags, related_branches, related_projects, created, last_reviewed
| title | source_type | url | archive_url | status | confidence | tags | related_branches | related_projects | created | last_reviewed | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| company-tech-blog / Netflix Tudum — CQRS Architecture Evolution (Kafka→RAW Hollow) | company-tech-blog | https://netflixtechblog.com/netflix-tudum-architecture-from-cqrs-with-kafka-to-cqrs-with-raw-hollow-86d141b72e52 | raw | medium |
|
|
|
2026-06-04 | 2026-06-04 |
Netflix Tudum — CQRS Architecture Evolution (Kafka → RAW Hollow)
Layer:
raw/company-tech-blogs/— Netflix TechBlog (2025) 에서 Netflix Tudum 팀이 Full CQRS (Kafka + Cassandra separate read store) 를 채택했다가 operational friction 으로 인해 RAW Hollow (in-memory) 로 대체한 사례. Full CQRS (Alt 3) 의 현실적 운영 비용과 eventual consistency 문제 의 production evidence.출처 신뢰도: Netflix TechBlog (official engineering blog). company-tech-blog 등급. official best practice 로 승격 금지 — Netflix 의 특정 use case (CMS-driven content site, 20M 사용자, editorial preview latency 문제) 에 특화된 결정.
Parent / 활용 branch (필수)
| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| raw/branch-notes/feature-application-query-bypass-contract | D3 (Full CQRS — separate data stores) 의 operational cost + eventual consistency 문제 의 production evidence. "언제 escalation 해야 하는가" 의 반대 사례 (escalation 후 다시 simpler 로 돌아간 케이스) |
출처 / Source
- 원본 URL: https://netflixtechblog.com/netflix-tudum-architecture-from-cqrs-with-kafka-to-cqrs-with-raw-hollow-86d141b72e52
- 아카이브 URL:
- 저자 / 조직: Netflix Technology Blog — Tudum Engineering Team
- 발행일: 2025 (exact date per TechBlog post)
- 마지막 확인일: 2026-06-04
- 검증 한계: netflixtechblog.com SSL 인증서 오류로 직접 WebFetch 불가. 아래 인용은 ByteByteGo 가 인용한 Netflix TechBlog 내용 기반 (secondary source, confidence: medium). bytebytego.com 에서 WebFetch 검증됨.
- 보조 확인: https://blog.bytebytego.com/p/how-netflix-tudum-supports-20-million (summary, WebFetch 검증됨), InfoQ 뉴스 보도 https://www.infoq.com/news/2025/08/netflix-tudum-cqrs-raw-hollow/
왜 저장했는지 / Why archived
Full CQRS (separate read store) 를 production 에서 실제로 채택했다가 복잡성·eventual consistency·preview latency 문제로 simpler architecture 로 전환한 사례. ca-tmpl skeleton 이 Full CQRS 를 "escalation only" 로 분류하는 결정의 반대 사례(counterargument source). "언제 Full CQRS 가 부적합한가" 의 production evidence.
핵심 인용 / Key quotes (verbatim, secondary source via ByteByteGo)
[§Architecture rationale] "To keep these workflows independent and allow each to scale according to its needs, Netflix adopted a CQRS (Command Query Responsibility Segregation) architecture."
[§Operational problem — eventual consistency] "Every time an editor made a change in the CMS, that change had to travel through a long chain before it appeared in a preview environment or on the live site."
[§Operational problem — preview latency] "editors had to sometimes wait minutes to see their changes reflected in a preview, even though the system had already processed and stored the update."
[§Migration rationale — complexity] "Removing Kafka, the external key-value store, and near-cache layers from the read path reduced moving parts and failure points, while eliminating cache-invalidation headaches."
[§RAW Hollow result] "RAW Hollow distributes that update to all Hollow clients across service instances...each instance has the full dataset in memory, any request...is served immediately without cache checks or datastore queries."
Claims Extracted / 추출된 주장
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| NETFLIX-TUDUM-C1 | Netflix Tudum 은 write path (editorial CMS) 와 read path (20M+ user site) 의 독립 scaling 을 위해 Full CQRS (Kafka + Cassandra separate read store) 를 채택했음 | "To keep these workflows independent and allow each to scale according to its needs, Netflix adopted a CQRS (Command Query Responsibility Segregation) architecture." | company-case-study |
write/read 부하가 극단적으로 비대칭인 시스템 (editorial write 소수 vs 20M user read 다수) | 단순 Java/Spring skeleton 애플리케이션에서 동일 근거로 Full CQRS 가 필요하다는 근거는 아님 |
| NETFLIX-TUDUM-C2 | Full CQRS 의 separate store 구조는 "긴 체인" 을 통한 eventual consistency 지연을 유발 — editor 가 변경 후 preview 에서 확인하기까지 "때로는 수 분" 대기 | "Every time an editor made a change in the CMS, that change had to travel through a long chain before it appeared in a preview environment" + "editors had to sometimes wait minutes to see their changes reflected" | company-case-study |
Kafka + separate store 를 통해 read model 을 갱신하는 Full CQRS 시스템 | 이 eventual consistency 지연이 모든 Full CQRS 시스템에서 나타난다는 뜻은 아님 — Netflix 의 Kafka pipeline 구성 특화 문제일 수 있음 |
| NETFLIX-TUDUM-C3 | separate store CQRS 의 이동 부품 (Kafka, external key-value store, near-cache) 제거가 장애 지점 감소와 운영 단순화를 가져옴 | "Removing Kafka, the external key-value store, and near-cache layers from the read path reduced moving parts and failure points, while eliminating cache-invalidation headaches." | company-case-study |
Full CQRS 에서 더 단순한 아키텍처로 migration 결정의 근거 | "Kafka + separate store 가 항상 이런 문제를 낳는다" 는 일반화 불가 — Netflix 의 전환 이유가 부분적으로 in-memory store (RAW Hollow) 의 등장 덕분 |
| NETFLIX-TUDUM-C4 | in-memory read store 로 전환 후 page construction time 이 약 1.4s → 0.4s 로 단축 (InfoQ 보도) | (InfoQ 보조 인용) "Home page construction time dropped from roughly 1.4 seconds to about 0.4 seconds once all read-path services consumed Hollow in-memory state." | company-case-study (secondary — InfoQ via search summary) |
in-memory 기반 read store 로 전환한 read-heavy production system | 일반 Java/Spring skeleton 에서 in-memory store 없이도 이 수준 성능을 달성해야 한다는 기준은 아님 |
Usage Boundaries / 적용 경계
- 이 자료가 직접 증명하는 것:
NETFLIX-TUDUM-C1: 극단적 write/read 비대칭 (소수 편집자 vs 20M 사용자) 이 Full CQRS separate store 채택 동기가 될 수 있음NETFLIX-TUDUM-C2~C3: separate store CQRS 의 운영 현실 — eventual consistency 지연 + "긴 체인" + 이동 부품 증가 = 운영 부담
- 이 자료가 증명하지 않는 것:
- Full CQRS 가 항상 eventual consistency 문제를 유발한다는 일반 규칙 — Netflix 의 특정 pipeline 구성 특화
- ca-tmpl skeleton 에서 Full CQRS 를 배제해야 한다는 직접 근거 — Netflix 는 Full CQRS 를 채택했고 다시 다른 방식으로 전환했을 뿐 (CQRS 자체를 폐기한 게 아님, RAW Hollow 도 CQRS)
- CQRS-lite (single store) 가 Full CQRS 보다 우월하다는 직접 비교 (Netflix 는 CQRS-lite 를 채택하지 않았음)
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- ca-tmpl skeleton 이 도달할 부하 수준과 Netflix Tudum (20M users) 의 비교 — 비교가 유효한지
- eventual consistency 허용 여부 — skeleton 의 기본 사용 도메인이 strong consistency 를 요구하는지
메모 / Notes
- Netflix 의 "CQRS → RAW Hollow" 전환은 "Full CQRS 는 나쁘다" 가 아니라 "더 단순한 read store 가 생겼으니 이동 부품을 줄이자" 의 실용적 결정
- ca-tmpl skeleton 의 escalation rule 에서: "read/write 부하가 명확히 비대칭이고 read store 기술 선택이 명확할 때" 만 Full CQRS 로 escalation 하는 조건의 반례(counterargument) 로 활용 가능
- confidence: medium — netflixtechblog.com 직접 접근 불가로 ByteByteGo/InfoQ secondary source 기반. 직접 접근 시 quotes 재검증 필요.
Related / 관련
- raw/official-docs/cqrs-pattern-azure-architecture-center — Full CQRS separate store 의 공식 정의 + complexity 경고
- raw/official-docs/cqrs-fowler-bliki — CQRS caution 경고
- raw/branch-notes/feature-application-query-bypass-contract — 본 자료를 소비하는 branch