86 lines
8.5 KiB
Markdown
86 lines
8.5 KiB
Markdown
---
|
|
title: company-tech-blog / Netflix Tudum — CQRS Architecture Evolution (Kafka→RAW Hollow)
|
|
source_type: company-tech-blog
|
|
url: https://netflixtechblog.com/netflix-tudum-architecture-from-cqrs-with-kafka-to-cqrs-with-raw-hollow-86d141b72e52
|
|
archive_url:
|
|
status: raw
|
|
confidence: medium
|
|
tags: [cqrs, read-model, separate-read-store, kafka, cassandra, eventual-consistency, netflix, ca-skeleton]
|
|
related_branches: [feature-application-query-bypass-contract]
|
|
related_projects: [ca-skeleton]
|
|
created: 2026-06-04
|
|
last_reviewed: 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
|