Event Sourcing & CQRS Mechanics

1. Overview

이벤트 소싱 및 CQRS 메커니즘(Event Sourcing & CQRS Mechanics, ESC)은 현재의 데이터만을 남기는 전통적인 저장 방식의 파괴적 혁신을 통해, 시스템의 모든 역사적 궤적을 수리적으로 완벽하게 복원하고 성능을 물리적으로 격리하는 분산 데이터 전술입니다.

학습자는 데이터의 최종 상태(State)가 아니라 발생한 사건(Event)들을 순차적으로 쌓는 이벤트 소싱의 물리 장부 기법을 배웁니다. 특히, 쓰기에 최적화된 이벤트 저장소와 읽기에 특화된 조회용 저장소를 물리적으로 나누는 CQRS의 결합 기재와 **프로젝션(Projection)**의 수리적 흐름을 익힙니다. 이를 통해 과거의 어떤 시점의 상태로도 즉시 되돌릴(Time-travel) 수 있고, 조회 부하가 쓰기 성능을 전혀 갉아먹지 않는 하이엔드 아키텍처 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• Event Sourcing Anatomy: 불변성(Immutability) 기반의 이벤트 로그 저장 및 재생(Replay) 물리
• CQRS Architectural Separation: Command(쓰기)와 Query(읽기) 모델의 수리적 격리
• Projection Dynamics: 이벤트를 해석하여 읽기 전용 저장소로 데이터를 굽는(Materialization) 수순
• Snapshotting in Event Sourcing: 재생 시간 단축을 위한 하드웨어 상태 요약 물리학
• Data Reconciliation: 읽기 모델과 쓰기 모델 사이의 일관성 간극 해결 수리 기법

Out-of-Scope

• 단일 DB 내부의 뷰(View) 및 트리거(Trigger) 최적화 (06-02-03 영역에서 분담)
• 분산 합의 알고리즘(Raft)의 복제 로그 수리 상세 (07-02-02 영역에서 분담)

Boundaries

• ESC vs. Distributed Transactions: 분산 트랜잭션(07-02-04)이 '원자성'에 집중한다면, ESC는 '상태 관리의 역사성'과 '모델 분리를 통한 처리량 확장'에 집중하여 구분합니다.

3. Counterexample

• 단순히 "로그 데이터 저장하기"라 설명하는 것은 ESC 학습이 아닙니다. 왜 이벤트 소싱에서 이벤트 스키마가 변경(Versioning)될 때 과거 데이터와의 수리적 호환성을 유지하는 '업캐스팅(Upcasting)'이 물리적 난제인지 증명할 수 있어야 하며, CQRS 도입 시 발생하는 '단기적 정합성 불일치'가 사용자 비즈니스에 미치는 물리적 파장을 산출할 수 없다면 ESC의 위험을 이해하지 못한 것입니다.

4. Prerequisites

• indexing & B-Tree Storage Mechanics (Basic): 파일 I/O 이해가 필수입니다. (06-01-02 IBS)
• Design Patterns for Distributed Systems (Recommended): CQRS의 기본 개념 이해가 권장됩니다. (07-01-04 DPD)

5. Learning Map

1. The Life Trace: 데이터의 현재 모습이 아닌, 탄생부터 지금까지의 '이야기'를 물리 저장합니다.
2. Infinite Recall: 저장된 이벤트들을 거꾸로 돌려(Reverse Replay) 과거의 진실을 수리 복구합니다.
3. Model Schism: 복잡해진 데이터 모델을 "주는 쪽(Command)"과 "보여주는 쪽(Query)"으로 물리 절단합니다.
4. Synchronized Split: 쪼개진 두 세계를 이벤트라는 물리적 가교(Bridge)로 실시간 연결하여 반응성을 완성합니다.

6. Learning Topics

Basic

Core: 이벤트 소싱의 기초와 영속성 (Event Sourcing Basics)

• Why to Learn: 유실 없는 데이터 히스토크리를 추적하고 완벽한 감사(Audit) 기능을 하드웨어 레벨에서 확보하기 위해서입니다.
• What to Learn:
  • Event Store: 오직 추가만 가능한(Append-only) 물리 로그 저장소
  • Aggregate Root: 이벤트를 수용하고 비즈니스 규칙을 검증하는 물리적 단위
  • Replay Mechanics: 로그를 순차 실행하여 현재 메모리 상태를 구성하는 수리 절차
• How to Learn:
  • '잔액 5,000원' 결과값 대신 '+1,000원', '-2,000원' 등 개별 이벤트를 하드웨어에 저장하고 합산하는 실습
  • 소스 코드를 수정하지 않고도 이벤트 재생만으로 버그를 재현하는 물리적 시뮬레이션
• Implement: 이벤트를 리스트에 담고 순회 처리하여 최종 객체 상태를 만드는 기초 EventSourcingAggregate

Recommended

Core: CQRS의 분리와 데이터 물리 (CQRS Mechanics)

• Why to Learn: 읽기 요청이 폭증해도 쓰기 시스템의 성능 전압(Pressure)을 물리적으로 받지 않기 위함입니다.
• What to Learn:
  • Command Model: 정합성 검증에만 집중하는 무거운 물리 객체
  • Query Model: 조회 대상(UI 등)에 딱 맞춰 조인 없이 저장된 가벼운 수리 객체
  • Divergent Architectures: 쓰기는 RDB에, 읽기는 NoSQL이나 Search Engine에 담는 물리 결합
• How to Learn:
  • 복잡한 조인 쿼리를 '미리 계산된 읽기 테이블'로 변환했을 때 하드웨어 조회 속도 향상분 측정 실습
  • 쓰기와 읽기 모델이 물리적으로 떨어졌을 때 발생하는 '업데이트 지연'의 허용 범위 산출
• Implement: 명령을 처리하는 서비스와 별도의 쿼리 데이터베이스를 조회하는 서비스의 물리 소통 구조

Practical

Core: 프로젝션과 스냅샷 공학 (Performance Scaling)

• Why to Learn: 수억 개의 이벤트를 매번 재생하는 물리적 비효율을 해결하고 데이터 마켓을 구축하기 위해서입니다.
• What to Learn:
  • Projectors: 이벤트를 실시간으로 읽어 읽기용 DB를 갱신하는 물리 파이프라인
  • Snapshotting: 1,000번째 이벤트마다 상태를 덤프하여 재생 시점을 단축하는 수리 기법
  • Denormalization Physics: 중복을 허용하여 조회 효율을 극도로 높이는 데이터 물리
• How to Learn:
  • 스냅샷 주기를 10개, 100개, 1,000개로 바꿨을 때의 메모리 로딩 속도와 디스크 사용량 상관관계 측정 실습
  • 비동기 프로젝션의 '최종적 일관성'이 깨졌을 때의 자가 치유(Self-healing) 절차 분석
• Implement: 이벤트를 구독하여 RDBMS의 요약 테이블을 업데이트하는 EventProjector

Advanced

Core: 도면 변경과 대규모 마이그레이션 (Evolution Physics)

• Why to Learn: 시스템이 성장하며 데이터 구조가 바뀔 때, 영구 저장된 과거 이벤트들을 안전하게 마이그레이션하기 위함입니다.
• What to Learn:
  • Upcasting: 과거의 낡은 이벤트를 런타임에 최신 수리 모델로 변환하는 변속기
  • Side Effects in Replay: 이벤트 재생 시 외부 API 호출이나 이메일 발송 같은 물리적 사고 방지 기제
  • Event Store Partitioning: 로그가 테라바이트급으로 커질 때의 하드웨어 물리 분할
• How to Learn:
  • '결제' 이벤트에 '세금' 필드가 추가되었을 때, 과거 데이터를 건드리지 않고 업캐스터를 통해 값을 보정하는 실습
  • '멱등성(Idempotency)'이 결여된 시스템에서 이벤트 재처리가 일으키는 하드웨어 연쇄 장애 시나리오 분석
• Implement: 데이터 버전을 감지하여 필드 정보를 보완해주는 EventSchemaUpcaster

7. Terminology

8. References

Primary

• [P2] SWEBOK v4.0 - Software Design / Software Structure and Architecture (Data-flow styles) — Structural context.
• [P1] CS2023 - DM/Data Management (Distributed systems and eventual consistency) — Core requirements.

Secondary

• [Designing Data-Intensive Applications (DDIA)] Martin Kleppmann — Event Sourcing and CQRS fundamentals.
• [Exploring CQRS and Event Sourcing] Microsoft patterns & practices — Detailed implementation patterns.

Industry

• [Greg Young: CQRS Documents] — The foundational papers on the subject.
• [Axon Framework: Concepts of Event Sourcing] — Practical enterprise implementation guide.

9. Final Checklist

Primary

• '이벤트 소싱' 아키텍처가 '상태 기반 저장' 방식보다 왜 물리적 데이터 복구(Disaster Recovery) 측면에서 우월한지 설명 가능한가? (P1)
• 'CQRS'를 통해 읽기 모델을 물리적으로 분리했을 때 얻을 수 있는 수평 확장성($Scalability$)의 수리적 한계를 기술할 수 있는 가? (P1)

Secondary

• '스냅샷(Snapshotting)'이 없는 이벤트 소싱 시스템에서 '이벤트 수'가 증가함에 따라 하드웨어 시동(Start-up) 시간이 지수적으로 증가하는 이유를 소통 가능한가?
• 프로젝션(Projection) 과정에서 발생하는 지연이 유저 인터페이스(UI)의 반응성에 미치는 물리적 파장을 논증할 수 있는 가?

Industry

• 전자상거래 시스템에서 '주문 히스토리'를 관리하기 위해 이벤트 소싱을 적용할 때의 물리적 저장소 용량 예측치를 산출할 수 있는 가? (SFIA)
• 기존 모놀리식 시스템을 CQRS 구조로 이행할 때, 서비스 중단 없이 읽기 모델을 물리적으로 구축하는 '섀도우 라이팅(Shadow Writing)' 절차를 분석할 수 있는 가?