실무에서의 이벤트 기반 아키텍처

이벤트 기반 아키텍처는 소유권을 더 분명하게 만들 때 가장 잘 작동한다. 메시지 브로커가 아무도 이름 붙이지 않은 의존성을 숨기기만 한다면 실패한다.

하나의 비즈니스 이벤트로 시작하기

주문 트랜잭션이 커밋된 뒤 생성되는 OrderPlaced 이벤트에서 시작했다. 이메일, 분석, 주문 처리 기능은 체크아웃 지연을 늘리지 않고 독립적으로 반응할 수 있었다.

type OrderPlaced = {
  id: string;
  occurredAt: string;
  orderId: string;
  customerId: string;
};

전달의 현실에 맞춰 설계하기

전달은 대개 최소 한 번 이상 일어난다. 따라서 컨슈머는 처리한 이벤트 ID를 저장하고, 부수 효과를 멱등적으로 만들며, 제한된 백오프로 재시도한다. 데드레터 큐는 운영 도구이지 소유권의 대체물이 아니다.

계약을 의도적으로 진화시키기

이벤트는 사실을 설명하며 프로듀서가 바뀐 뒤에도 유용해야 한다. 선택 필드를 추가하고, 기존 필드를 새 의미로 해석하지 않으며, 의미가 바뀔 때는 새 이벤트 타입을 발행한다.

무엇이 나아졌나

체크아웃은 더 작아졌고, 다운스트림 실패가 구매를 막지 않게 되었으며, 팀들은 컨슈머를 독립적으로 배포할 수 있었다. 트레이드오프는 운영 측면에 있었다. 트레이스, 지연 지표, 재생 도구가 필수가 되었다.