개념 정의를 외웠는지가 아니라 이벤트 소싱을 언제 들이고 언제 피해야 하는지, 스냅샷·스키마 진화·CQRS까지 묶어서 운영 트레이드오프를 말할 수 있는지를 본다. 장점만 줄줄 읊으면 "단점은요?"로 바로 깊이가 갈린다.
이벤트 소싱은 현재 상태를 덮어쓰지 않고, 상태를 바꾼 이벤트 자체를 시간순으로 쌓아 두는 저장 방식이다. 지금 잔고를 알고 싶으면 처음부터 이벤트를 재생(replay)해서 상태를 다시 만든다. "어떻게 이 상태가 됐는지"를 항상 되짚을 수 있지만, 읽을 때마다 비용이 든다. 스냅샷으로 재생 기점을 앞당기고, CQRS로 읽기 모델을 별도 관리해야 실제로 굴러간다.
주문·결제 상태를 사후에 재구성해야 했던 경험이 있다면 그때의 한계와 이벤트 소싱이 어떻게 답이 됐을지를 연결할 수 있다
감사 로그나 변경 이력 테이블을 따로 운영해본 적이 있다면 그 운영 부담과 이벤트 소싱 도입 비용을 같은 축에서 비교할 수 있다
스키마 변경으로 과거 데이터를 못 읽었던 경험이 있다면 이벤트 버전 진화 정책의 필요성으로 자연스럽게 이어진다
CQRS·읽기 모델을 따로 둔 프로젝트 경험이 있다면 이벤트 소싱과 결합했을 때 얻는 효과를 본인 사례로 풀 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.