---
title: Wix Engineering — Debezium / CDC production 사례 (인용 검증 실패)
source_type: company-tech-blog
url: https://medium.com/wix-engineering/how-wix-uses-debezium-and-kafka-for-data-replication-and-cdc-cdce0c6b3cd1
archive_url:
status: needs-confirmation
confidence: low
tags: [ca-outbox-pattern, wix, debezium, cdc, production-case, company-case-study, unverified-source]
related_branches: [feature-domain-event-outbox-contract, feature-background-job-async-contract]
related_projects: [ca-skeleton-operational-contract]
created: 2026-05-22
last_reviewed: 2026-05-27
---

# Wix Engineering — Debezium / CDC 사례 (직접 검증 실패)

> Layer: `raw/company-tech-blogs/` — Wix Engineering Medium blog. ca-tmpl outbox 6대안 중 **대안 1 (Debezium CDC) 의 production 사례** 로 보관.
>
> **출처 신뢰도 경고 — 중요**: company-tech-blog + **원본 URL 4개 모두 404 (페이지 제거됨)**. WebFetch 시점(2026-05-27) 에 medium.com Wix Engineering 의 해당 글 + 보조 검색 결과(wix.engineering/post/scaling-to-the-moon-mysql-debezium-kafka, /post/exactly-once-message-delivery-from-mysql-to-kafka, /post/wix-greyhound-debezium-kafka) 가 모두 404. wix.engineering/blog 메인의 최근 5페이지에도 Debezium/CDC 관련 article 부재. 따라서 본 문서의 인용은 **모두 미검증 (needs-confirmation)**, 본 자료를 outbox 결정 근거로 인용 시 별도 archive.org 스냅샷 또는 컨퍼런스 발표 자료로 보강 필요.

## Parent / 활용 branch (필수)

| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| [[raw/branch-notes/feature-domain-event-outbox-contract]] | outbox 6대안 비교에서 "Debezium CDC production 사례" 위치 — 단, 본 자료가 미검증이므로 인용 시 보조 자료 필수 |
| [[raw/branch-notes/feature-background-job-async-contract]] | application polling vs CDC-based propagation 의 production 운영 비용 비교 reference (미검증) |

특정 branch 없이 foundational 조사로 수집한 경우:

- [[raw/project-notes/ca-skeleton-operational-contract]] — Contract #19 의 outbox 결정에서 "CDC 가 dual-write 를 제거한다" 일반 주장의 사례 후보 (검증 미달로 1차 근거 부적격)

## 컨텍스트 / 왜 저장했는지

ca-tmpl 의 SKIP LOCKED 결정에 대한 **CDC 기반 outbox 의 실제 production 운영 사례** 후보. Debezium 이 단순 토이가 아니라 대규모 production 에서 어떻게 굴러가는지 확인 목적. 단 원본 URL 이 모두 제거되어 wording 검증 불가.

## 출처 / Source

- 원본 URL: https://medium.com/wix-engineering/how-wix-uses-debezium-and-kafka-for-data-replication-and-cdc-cdce0c6b3cd1 (HTTP 404 — 2026-05-27 확인)
- 시도한 보조 URL (모두 404):
  - https://medium.com/wix-engineering/scaling-to-the-moon-mysql-debezium-kafka-event-streaming-9a07ade5410d
  - https://www.wix.engineering/post/scaling-to-the-moon-mysql-debezium-kafka
  - https://www.wix.engineering/post/exactly-once-message-delivery-from-mysql-to-kafka
  - https://www.wix.engineering/post/wix-greyhound-debezium-kafka
  - https://www.wix.engineering/post/wix-architecture-at-scale-mysql
  - https://www.wix.engineering/post/event-driven-architecture-5-pitfalls-to-avoid
- wix.engineering/blog 메인 (페이지 1) 에서도 Debezium/CDC/Kafka outbox 관련 최근 글 부재 (2026-05-27 확인)
- 아카이브 URL: (미수집 — archive.org 재시도 필요)
- 저자 / 조직: Wix Engineering (Medium)
- 발행일: 불명 (페이지 제거)
- 마지막 확인일: 2026-05-27

## 핵심 인용 / Key quotes (verbatim — 모두 미검증)

> **경고**: 아래 인용은 원본 URL 이 검증 시점에 404 인 상태에서 보관 중인 사전 정리본. 원문 wording 검증 불가 → strength = `needs-confirmation`.

> [§미검증 — 보관용 wording] "We use Debezium to capture changes from our MySQL databases and stream them to Kafka, decoupling write paths from downstream consumers."

> [§미검증 — 보관용 wording] "Application services do not publish to Kafka directly; they write to their own database, and Debezium handles propagation."

> [§미검증 — 보관용 wording] "This avoids dual-writes and ensures that any change persisted in the source DB will eventually appear in Kafka."

## Claims Extracted / 추출된 주장

> **중요**: 본 자료는 원본 URL 404 로 인용 검증 실패 상태. 아래 claim 들은 모두 strength `needs-confirmation` — 적용 결정의 근거로 단독 인용 금지. 별도 검증된 자료 (`raw/company-tech-blogs/outbox-confluent-kafka-connect-smt`, `raw/official-docs/event-sourcing-vs-outbox-microservices-io`, 또는 Debezium 공식 문서) 와 조합 필요.

| Claim ID | Claim (이 자료가 직접 말한다고 보관된 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| WIX-DEBEZIUM-C1 | Wix 는 Debezium 으로 MySQL 변경을 capture 하여 Kafka 로 stream 하고, 이를 통해 write path 와 downstream consumer 를 decouple 한다 (미검증) | [§미검증 — 보관용 wording] "We use Debezium to capture changes from our MySQL databases and stream them to Kafka, decoupling write paths from downstream consumers." | `needs-confirmation` | (조건부) Wix 의 production 아키텍처 사례 — wording 검증 후 `company-case-study` 로 승급 가능 | "Debezium 이 outbox 의 표준 해법" 이라는 일반화 금지. 본 자료가 검증되어도 단일 사례. |
| WIX-DEBEZIUM-C2 | Wix 의 application service 는 Kafka 에 직접 publish 하지 않고 자신의 DB 에만 쓰며, Debezium 이 propagation 을 처리 (미검증) | [§미검증 — 보관용 wording] "Application services do not publish to Kafka directly; they write to their own database, and Debezium handles propagation." | `needs-confirmation` | (조건부) outbox/CDC 패턴의 "DB-only write" 원칙의 production 적용 reference | application 측 idempotency 요구사항이 사라진다는 뜻은 아님 — at-least-once 기본 가정 별도 |
| WIX-DEBEZIUM-C3 | 이 방식이 dual-writes 를 회피하며 source DB 에 persist 된 변경이 결국 Kafka 에 나타나는 것을 보장 (미검증) | [§미검증 — 보관용 wording] "This avoids dual-writes and ensures that any change persisted in the source DB will eventually appear in Kafka." | `needs-confirmation` | (조건부) CDC 기반 outbox 의 dual-write 회피 효과 사례 | "exactly-once" 가 아니라 "eventually" — 본 wording 도 eventual consistency 한정 |

## Usage Boundaries / 적용 경계

- **이 자료가 직접 증명하는 것**:
  - **없음** (원본 URL 404 — 모든 claim 이 미검증 상태)
- **이 자료가 증명하지 않는 것**:
  - Debezium 이 outbox 의 표준 해법이라는 일반화
  - dual-write 회피의 일반론 (Wix 사례 한정, 게다가 검증 실패)
  - Debezium connector 운영의 구체 trade-off (schema migration, WAL 적체 등)
  - Wix 가 application polling 대신 CDC 를 선택한 의사결정 과정
  - "조직 규모 → polling vs CDC 결정" 의 일반 규칙
- **내 프로젝트에 적용하려면 추가 확인이 필요한 것**:
  - **원본 wording 의 archive.org 스냅샷 수집** (필수 — 인용 검증)
  - Wix 의 컨퍼런스 발표 (KubeCon, Devoxx 등) 에서 동일 주장 보강
  - Debezium 공식 문서 (`debezium.io/documentation/reference/`) 의 outbox EventRouter 섹션과 비교
  - ca-tmpl 의 write throughput 이 Wix 사례와 같은 CDC 도입 임계점인지 평가

## 메모 / Notes (내 프로젝트 해석)

> 본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석. **단, 본 자료 자체가 미검증이므로 아래 메모도 보강 자료 없이 단독 사용 금지.**

- 적용 시나리오: 마이크로서비스 다수, write 트래픽이 크고 downstream consumer 가 많은 조직.
- 장점 (Wix 가 언급했다고 보관된 것 — 미검증):
  - dual-write 제거 → 신뢰성 향상
  - downstream 추가가 쉬움 (새 consumer 만 붙이면 됨, source 코드 무변경)
  - 분석/검색 인덱스 등 secondary store 에 자동 sync
- 단점 (production 운영하며 드러나는 것 — 일반 통념):
  - Debezium connector 자체의 운영 (offset, schema, HA) 부담이 큼
  - schema migration 시 connector 영향 검토 필요
  - large transactions / long-running transactions 가 WAL 적체 → lag 유발
- ca-tmpl(SKIP LOCKED polling) 과의 차이:
  - Wix 규모면 polling overhead 가 비현실적 → CDC 가 사실상 필수
  - ca-tmpl 규모(템플릿 수준) 에서는 Wix 식 인프라가 **과투자**
- 운영 복잡도: 높음. Kafka Connect cluster 전담 운영 인력/지식 필요.
- exactly-once / at-least-once 보장 수준: at-least-once. consumer idempotency 전제 (본 인용에서 직접 증명 안 됨).
- 외부 의존성 추가 여부: Kafka, Kafka Connect, Debezium, (Schema Registry).
- 시사점: "조직 규모와 downstream fan-out 수" 가 polling vs CDC 선택의 결정 변수 — 단, 본 자료가 검증 실패이므로 이 주장의 근거로는 Netflix DBLog (`outbox-netflix-domain-events-cdc`) + Debezium 공식 문서 조합을 사용해야 함.

## Related / 관련

- 같은 주제 다른 raw 자료:
  - [[raw/official-docs/event-sourcing-vs-outbox-microservices-io]] (대안 4: event sourcing — 검증됨)
  - [[raw/company-tech-blogs/outbox-confluent-kafka-connect-smt]] (대안 2: Confluent SMT — 부분 검증)
  - [[raw/company-tech-blogs/outbox-netflix-domain-events-cdc]] (대안 6: Netflix DBLog — arXiv 검증)
  - [[raw/company-tech-blogs/domain-event-sourcing-vs-cqrs-greg-young]] (event/CQRS 정의 정리)
- 인용하는 branch:
  - [[raw/branch-notes/feature-domain-event-outbox-contract]]
  - [[raw/branch-notes/feature-background-job-async-contract]]
- 인용하는 wiki: (미작성)

## Followup TODO

- [ ] archive.org 에서 원본 4개 URL 스냅샷 검색 → wording 검증
- [ ] Wix 의 컨퍼런스 발표 (YouTube / SlideShare) 검색하여 동일 주장 보강
- [ ] Debezium 공식 문서 outbox EventRouter 섹션을 별도 `raw/official-docs/debezium-outbox-event-router.md` 로 분리하여 1차 근거 확보