CQRS 패턴 적용

채팅방 100개에 쓰지 않는다 — CQRS 스냅샷으로 거래 상태 읽기 병목을 줄인 이유

ValueHub는 상품 DB와 채팅 DB가 처음부터 분리되어 있습니다. 예약이 확정되면 그 상품과 연결된 모든 채팅 헤더에 예약중이 보여야 합니다. 이 글은 방 Document마다 상태를 복사하지 않고, Chat 전용 읽기 모델(chat_product_posts) 한 줄로 수렴시킨 CQRS 선택과 동기화 전략을 정리합니다.

1. 개요 및 배경 (Context & Problem)

• 동기 REST 조회: 읽기 결합 + 장애 전파.

• 방마다 상태 복제: 쓰기 증폭 + 부분 갱신 불일치.

• 모놀리식 단일 DB: 배포·확장 경계 소실, 실시간 워크로드와 거래 원본의 경합. 필요한 것은 “항상 원본과 강한 일관성”이 아니라, 채팅 화면이 빠르게 읽는 로컬 모델과 원본 변경을 한 번의 쓰기로 반영하는 경로였습니다.

2. 왜 이 기술을 선택했는가? (Why This Technology?)

• 쓰기 증폭 방지: 1:N I/O 병목을 1:1 업데이트로 줄인다.

• 장애 전파 차단: 로컬 읽기 모델로 채팅 조회 성능을 원본 서비스 SLA에서 분리한다. 방에는 productPostUuid만 둡니다. 이름·가격·이미지·tradeStatus는 chat_product_posts(PK = productPostUuid) 한 행입니다. 같은 상품의 채팅방 100개가 그 한 행을 공유합니다. 예약 이벤트가 오면 방 100개가 아니라 스냅샷 1건만 RESERVED가 됩니다. 100방 기준 상태 쓰기는 1/100입니다. 왜 MongoDB 방 문서가 아니라 MySQL 스냅샷인가. 거래 상태는 메시지처럼 무한히 쌓이지 않고, PK 조회·갱신 패턴이 관계형에 잘 맞습니다. 메시지 본문과 미리보기(last_message)는 MongoDB에 남깁니다. 문서형 워크로드와 상품 헤더 워크로드를 같은 컬렉션에 넣지 않았습니다. 왜 Kafka로 동기화하는가. Chat이 Product-Post를 구독하는 것이 아니라, 예약이라는 도메인 이벤트를 구독합니다. 거래 상태를 바꾸는 실제 커맨드는 예약 확정입니다. Product-Post도 같은 토픽을 소비해 자기 원본 listing을 갱신합니다. Chat의 스냅샷은 그 커맨드의 투영(projection)입니다. 의사결정 기준:

화면이 같은 값을 100번 읽더라도, 상태 전이는 한 번만 쓴다. 그 한 번은 예약 커밋 이후의 이벤트여야 한다.

3. 핵심 아키텍처 및 구현 흐름 (Implementation Flow)

동기화 흐름 6단계

[1] 방 생성 (REST, Kafka 없음)
      Mongo rooms INSERT  — productPostUuid만 저장
      MySQL chat_product_posts INSERT (없을 때만)
      MySQL chat_user_profiles UPSERT
[2] 채팅 읽기 (Query)
      방 목록/상세 = rooms ⋈ chat_product_posts ⋈ profiles
      Product-Post HTTP 없음
[3] 예약 Command
      Gateway → X-Member-Uuid → Reservations
      reservations_db COMMIT
[4] afterCommit
      reservation.events (key = productPostUuid, type = CREATED)
[5] 투영 (Chat Consumer)
      chat_product_posts 1건 → RESERVED
      Mongo 예약 메시지 + last_message
      STOMP 헤더/목록 패치
[6] 투영 (Product Consumer)
      listing tradeStatus 1건 → RESERVED
      채팅 조회 경로와 무관

flowchart TB
  classDef kafka fill:#fff7ed,stroke:#ea580c,stroke-width:2px
  subgraph command [Write / Command]
    RSV[Reservations] --> RDB[(reservations_db)]
    PP[Product-Post] --> PDB[(product_post_db)]
  end
  subgraph query [Read / Chat Query]
    CH[Chat-Service] --> SNAP[(chat_product_posts)]
    CH --> Mongo[(rooms / messages / last_message)]
    CH --> PROF[(chat_user_profiles)]
  end
  FE[Next.js] -->|REST / STOMP| GW[Spring Cloud Gateway]
  GW -->|X-Member-Uuid| RSV
  GW --> CH
  GW --> PP
  RSV -.->|afterCommit| K[Kafka reservation.events]
  K -.->|스냅샷 1건| CH
  K -.->|listing 1건| PP
  CH -->|STOMP 헤더 패치| FE
  class K kafka

private ChatProductPost markHeaderReserved(ChatProductPost productPost) {
    if (productPost == null) {
        log.warn("reservation.events CREATED: product snapshot missing, header skipped");
        return null;
    }
    return saveChatProductPostPort.save(productPost.markReserved());
}

같은 유스케이스에서 예약 말풍선과 last_message를 갱신하므로, 헤더가 RESERVED인데 목록 미리보기는 이전 대화인 상태를 줄입니다. 읽기 모델이 두 개(스냅샷 테이블 + 방 last_message)라도, 한 소비자 안에서 같이 맞춥니다. 프론트는 방 상세 REST로 받은 productPost.tradeStatus를 헤더에 그리고, 이후 패치는 STOMP /user/queue/chat-list의 productPost 필드로 덮습니다. 읽기 모델의 변경이 다음 전체 새로고침을 기다리지 않습니다.

4. 트러블슈팅 및 고려했던 점 (Troubleshooting & Deep Dive)

4.1 스냅샷이 없는 방을 어떻게 할 것인가

4.2 읽기 지연을 사용자에게 숨기는 지점

4.3 방 문서에 상태를 남겨 두면 안 되는 이유

4.4 취소·수정은 아직 투영하지 않는다

4.5 Gateway와 인증은 읽기 모델과 별개다

4.6 메시지 쓰기와 헤더 쓰기를 같은 Mongo 컬렉션에 넣지 않은 이유

대화량은 상태 전이보다 두 자릿수 이상 많습니다. 메시지 INSERT가 많은 컬렉션에 상품 상태 필드를 두면, 헤더 갱신이 채팅 I/O와 락을 공유합니다. 헤더 PK 갱신을 MySQL로 분리한 것은 CQRS라기보다 워크로드 분리입니다. 둘을 같이 했을 때 이득이 분명했습니다.

5. 마치며 (Summary)

• 방 N개에 거래 상태를 복제하지 않고 chat_product_posts 1건을 읽기 모델로 두어, 예약 1회의 헤더 쓰기를 1/N로 줄였습니다.

• 채팅 조회가 Product-Post REST에 묶이지 않아, 원본 서비스 장애와 실시간 채팅 읽기 경로를 분리했습니다.

• 동기화는 예약 afterCommit의 reservation.events 투영으로만 수행해, 커맨드 원본과 채팅 화면이 같은 이벤트를 기준으로 수렴하게 했습니다.