9.7 KiB
9.7 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 | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Event Sourcing as an Alternative to Outbox (microservices.io) | official-doc | https://microservices.io/patterns/data/event-sourcing.html | raw | high |
|
|
|
2026-05-22 | 2026-05-27 |
Event Sourcing as an Alternative to Outbox (microservices.io)
Layer:
raw/official-docs/— microservices.io 의 "Pattern: Event sourcing" 문서. ca-tmpl outbox 대안 중 대안 4 (event sourcing — 도메인 모델 자체 교체) 의 1차 근거.
Parent / 활용 branch (필수)
| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| raw/branch-notes/feature-domain-event-outbox-contract | outbox 6대안 비교에서 "event sourcing" 위치 — outbox 자체가 불요해지는 모델로 분류하는 근거 |
| raw/branch-notes/feature-background-job-async-contract | event 발행을 background job 으로 처리할지 vs event store 내장 subscriber 로 처리할지의 분기 근거 |
특정 branch 없이 foundational 조사로 수집한 경우:
- raw/project-notes/ca-skeleton-operational-contract — Contract #19 (Domain Application Readiness Contract) 의 Domain Event / Outbox 항목에서 event sourcing 채택 안 함의 근거 자료
컨텍스트
ca-tmpl 의 SKIP LOCKED outbox 결정에 대한 대안 4: event sourcing. outbox 자체가 불요해지는 모델 — event store 가 source of truth 가 되므로 별도 발행 메커니즘이 필요 없거나 매우 단순해짐.
출처 / Source
- 원본 URL: https://microservices.io/patterns/data/event-sourcing.html
- 아카이브 URL: (미수집)
- 저자 / 조직: Chris Richardson (microservices.io)
- 발행일: rolling (microservices.io patterns catalog)
- 마지막 확인일: 2026-05-27
- 보조 자료: Confluent blog "Event Sourcing, CQRS, and Stream Processing" (
https://www.confluent.io/blog/event-sourcing-cqrs-stream-processing-apache-kafka-whats-connection/)
핵심 인용 / Key quotes (verbatim)
[§Solution] "Event sourcing persists the state of a business entity such an Order or a Customer as a sequence of state-changing events."
[§Solution] "Whenever the state of a business entity changes, a new event is appended to the list of events."
[§Solution] "Since saving an event is a single operation, it is inherently atomic."
[§Solution] "The application reconstructs an entity's current state by replaying the events."
[§Solution] "When a service saves an event in the event store, it is delivered to all interested subscribers."
[§Resulting Context — Benefits] "It solves one of the key problems in implementing an event-driven architecture and makes it possible to reliably publish events whenever state changes."
[§Resulting Context — Drawbacks] "The event store is difficult to query since it requires typical queries to reconstruct the state of the business entities."
보조 인용 (Confluent blog, 동일 주제):
[Confluent — Event Sourcing, CQRS, and Stream Processing] "Event sourcing involves modeling the state changes made by applications as an immutable sequence or 'log' of events."
Claims Extracted / 추출된 주장
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| ES-OUTBOX-C1 | Event sourcing 은 business entity 의 state 를 일련의 state-changing events 의 sequence 로 영속화한다 | [§Solution] "Event sourcing persists the state of a business entity such an Order or a Customer as a sequence of state-changing events." | official-reference |
event sourcing 채택 시스템의 영속화 모델 정의 | event sourcing 이 모든 도메인에 적합하다는 뜻은 아님 — drawback 인용 별도 |
| ES-OUTBOX-C2 | event 저장은 단일 operation 이므로 본질적으로 atomic — 즉 dual-write 문제가 발생하지 않는 구조 | [§Solution] "Since saving an event is a single operation, it is inherently atomic." | official-reference |
event store 가 단일 transaction 단위로 event 를 추가하는 영속화 경계 | "DB + Kafka 두 시스템에 동시 쓰기가 자동으로 atomic" 이라는 뜻은 아님 — event store 단일 시스템 내부에서만 |
| ES-OUTBOX-C3 | 현재 상태는 events 를 replay 함으로써 재구성된다 (저장된 것은 events, 계산되는 것은 state) | [§Solution] "The application reconstructs an entity's current state by replaying the events." | official-reference |
event sourcing 의 read path 메커니즘 | replay 비용이 항상 허용 가능하다는 뜻은 아님 — snapshot 필요성은 별도 |
| ES-OUTBOX-C4 | event store 에 event 가 저장되면 모든 관심 있는 subscriber 에게 전달된다 → 별도 발행 메커니즘(outbox/CDC) 의 역할이 event store 자체로 흡수 | [§Solution] "When a service saves an event in the event store, it is delivered to all interested subscribers." | official-reference |
event store 가 내장 subscription 기능을 제공하는 구현 (EventStoreDB, Axon 등) | "subscriber 전달이 exactly-once" 라는 뜻은 아님 — delivery semantics 본 인용에 미명시 |
| ES-OUTBOX-C5 | event sourcing 은 event-driven architecture 구현의 핵심 문제(상태 변경 시 안정적 event 발행) 를 해결한다 | [§Resulting Context — Benefits] "It solves one of the key problems in implementing an event-driven architecture and makes it possible to reliably publish events whenever state changes." | official-reference |
event-driven architecture 의 dual-write 문제 컨텍스트 | "outbox 보다 항상 우수하다" 는 뜻은 아님 — 트레이드오프 별도 |
| ES-OUTBOX-C6 | event store 는 query 가 어렵다 — 일반 query 가 entity state 재구성을 요구하기 때문 | [§Resulting Context — Drawbacks] "The event store is difficult to query since it requires typical queries to reconstruct the state of the business entities." | official-reference |
event sourcing 의 read model 운영 부담 | CQRS read model 분리가 의무라는 뜻은 아님 — 권장 패턴일 뿐 |
Usage Boundaries / 적용 경계
- 이 자료가 직접 증명하는 것:
ES-OUTBOX-C1~C3: event sourcing 의 정의·atomicity·replay 메커니즘ES-OUTBOX-C4~C5: event sourcing 이 outbox 와 같은 별도 발행 메커니즘의 필요성을 흡수한다는 사실ES-OUTBOX-C6: event sourcing 의 query 어려움 (CQRS / snapshot / projection 필요성의 근거)
- 이 자료가 증명하지 않는 것:
- event sourcing 이 outbox/SKIP LOCKED 보다 "더 나은 선택" 이라는 일반적 권고
- 기존 CRUD 시스템에서 event sourcing 으로 마이그레이션 비용 구체적 산정
- event store 의 EOS (exactly-once) 보장 — 본 페이지는 delivery semantics 미명시
- Spring/JPA 기반 도메인에서 event sourcing 도입의 ORM 충돌 정도
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- ca-tmpl 의 도메인이 event sourcing 에 적합한가 (금융/감사 로그 중심 vs 단순 CRUD)
- team 의 CQRS/projection 운영 경험 수준 — event sourcing 학습 곡선 평가
- event store 도구 선택 (EventStoreDB / Axon / Kafka-as-log) 의 운영 비용
메모 / Notes (내 프로젝트 해석)
본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.
- 적용 시나리오: 도메인이 본질적으로 event-driven (금융 거래, 주문 상태 전이, 감사 로그가 핵심). 팀이 CQRS / projection 운영에 익숙한 경우.
- 장점:
- outbox 불요 — event 자체가 저장 단위 (
ES-OUTBOX-C2+C4결합 해석) - 완전한 audit log (모든 상태 변화가 보존)
- replay 로 신규 read model 구축 자유로움
- temporal query (과거 시점 상태 재구성) 가능
- outbox 불요 — event 자체가 저장 단위 (
- 단점:
- 현재 상태 조회가 비싸다 (
ES-OUTBOX-C6) → snapshot / projection 인프라 필요 - 학습 곡선 가파름 (CQRS, eventual consistency, projection 재구축 등)
- schema evolution (event 버전 관리) 부담
- 기존 CRUD 시스템에서 마이그레이션 비용 큼
- 일반적 ORM/JPA workflow 와 충돌
- 현재 상태 조회가 비싸다 (
- ca-tmpl(SKIP LOCKED polling) 과의 차이:
- outbox 는 기존 CRUD + 이벤트 발행 하이브리드. event sourcing 은 저장 모델 자체를 교체.
- "보조 발행 메커니즘" 이 아니라 "도메인 모델 패러다임 전환" 이라 의사결정 스케일이 다름
- 운영 복잡도: 높음. event store + projection + snapshot 운영.
- exactly-once / at-least-once 보장 수준: 발행은 여전히 at-least-once 가정 안전 (본 페이지 미명시 — 별도 검증 필요).
- 외부 의존성 추가 여부: event store (EventStoreDB, Kafka as log, Axon 등) 또는 자체 구축.
- 결론: ca-tmpl 같은 기존 CRUD-based 도메인에 event sourcing 을 도입하는 것은 outbox 의 "대안" 이 아니라 "전혀 다른 도메인 설계 선택" 에 가까움. 트레이드오프 폭이 가장 큼.
Related / 관련
- 같은 주제 다른 raw 자료:
- raw/company-tech-blogs/domain-event-sourcing-vs-cqrs-greg-young (event sourcing vs CQRS 구분 — Greg Young 원작자)
- raw/company-tech-blogs/outbox-confluent-kafka-connect-smt (대안 2: Kafka Connect SMT)
- raw/company-tech-blogs/outbox-netflix-domain-events-cdc (대안 6: Netflix DBLog)
- raw/company-tech-blogs/outbox-wix-engineering-debezium (대안 1 사례: Wix Debezium production)
- 인용하는 branch:
- 인용하는 wiki: (미작성)