이벤트 기반 아키텍처

서비스가 서로를 직접 부르지 않고 일어난 사실을 알리고, 관심 있는 쪽이 반응하는 구조입니다.

주문이 생겼을 때를 비교하면 이렇습니다.

두 번째에서 적립 기능을 추가할 때 주문 서비스를 고치지 않는다는 것이 이 구조의 값입니다.

흔한 실수: 이벤트에 명령을 담는 것. "재고를 차감하라"는 이벤트가 아니라 명령입니다. 이벤트는 이미 일어난 사실을 과거형으로 알리고, 무엇을 할지는 받는 쪽이 정합니다.

판단 기준은 사용자가 그 결과를 지금 알아야 하는가입니다.

한 요청 안에서 섞는 것이 보통입니다. 꼭 필요한 것만 동기로 처리하고 나머지를 큐로 넘기면, 응답은 빠르고 실패 지점은 줄어듭니다.

흔한 실수: 비동기가 더 빠르다고 답하는 것. 전체 처리 시간은 오히려 늡니다. 짧아지는 것은 사용자가 기다리는 구간입니다.

현재 상태를 저장하지 않고 변경 사건을 순서대로 저장하는 방식입니다. 상태는 그 사건들을 재생해서 만듭니다.

그래서 전면 도입보다 이력과 감사가 중요한 일부 영역에만 쓰는 편이 현실적입니다. 잔액 변동, 주문 상태 변화 정도입니다.

흔한 실수: 이벤트 드리븐 아키텍처와 같은 것으로 보는 것. 전자는 저장 방식이고 후자는 서비스 간 통신 방식입니다. 각각 따로 쓸 수 있습니다.

쓰기 모델과 읽기 모델을 분리하는 패턴입니다. 같은 데이터를 다루지만 구조를 따로 둡니다.

분리하는 이유는 두 요구가 충돌하기 때문입니다. 쓰기는 정규화가 유리하고, 조회는 조인 없이 한 번에 읽는 편이 빠릅니다. 하나의 모델로는 둘 다 만족하기 어렵습니다.

동기화는 이벤트로 합니다. 쓰기가 일어나면 이벤트를 발행하고 읽기 모델을 갱신합니다. 그래서 읽기 모델은 항상 조금 뒤처집니다.

흔한 실수: 읽기와 쓰기를 분리하니 무조건 도입하는 것. 조회 요구가 특별히 복잡하지 않으면 대가만 남습니다. 그리고 읽기 전용 복제본을 쓰는 것과 혼동하기 쉬운데, 복제본은 같은 모델의 사본이고 CQRS 는 모델 자체가 다릅니다.