← 질문 목록
#10깊이 0
이벤트 소싱을 도입할 때의 트레이드오프는 무엇인가?
이벤트 소싱은 이력을 통째로 남긴다. 대신 복잡도가 오른다. 현재 상태를 알려면 이벤트를 다시 재생해야 한다. 스트림이 길어지면 재생 비용 탓에 조회가 느려져, 조회용 모델이나 스냅샷을 따로 둔다.
- 이벤트 발생
그다음은 이벤트 저장소입니다. 상태 변경 이벤트 저장
이벤트 저장소그다음은 프로젝션입니다. 이벤트를 읽어 읽기 모델 갱신
프로젝션그다음은 읽기 모델입니다. 최종 상태 저장
읽기 모델
데이터를 최종 상태로 저장하지 않고 발생한 모든 이벤트를 저장하기 때문이다. 상태를 알기 위해 이벤트를 순차적으로 재생해야 한다. 이 과정에서 읽기 성능 저하가 발생한다. 그래서 읽기 전용 모델을 따로 두는 CQRS를 함께 쓰는 경우가 많다.
이벤트 저장소(Event Store)의 데이터가 계속 쌓이면 재생 시간이 길어진다. 재생 비용은 특정 시점의 상태를 스냅샷으로 저장해 줄인다.
이후 데이터 구조 변경이 필요할 때 문제가 된다. 과거의 이벤트를 수정할 수 없으며, 새로운 버전의 이벤트 스키마로 하위 호환성을 유지하는 업캐스팅(Upcasting) 같은 이벤트 진화 전략이 필요하다. 이는 개발 및 유지보수 비용을 중심으로 한 트레이드오프다.