4편에서는 payment-command가 결제 성공 이벤트(PaymentCapturedEvent)를 Kafka(payment-events)로 발행하고, order-command가 이를 구독해 MySQL 주문 상태를 PAID로 갱신한 뒤 OrderPaidEvent를 order-events로 재발행합니다. order-query는 이벤트 타입을 분기 소비해 Redis Read Model을 PAID로 업데이트하며 “결제→주문반영→조회갱신” 체인을 완성합니다.
3편에서는 order-command가 주문을 MySQL(JPA)에 저장하고 Kafka로 OrderCreatedEvent를 발행, order-query가 이를 구독해 Redis Read Model을 갱신합니다. 즉 “쓰기→이벤트→읽기 모델→조회” CQRS 핵심 흐름을 완성합니다.
CQRS 실습 시리즈 1편에서는 주문/결제/주문내역 도메인을 대규모 트래픽 관점에서 바라보며, 쓰기(Command)와 읽기(Query)를 분리하는 목표와 기본 가정을 정리합니다. 이어서 order-command, payment-command, order-query로 서비스 경계를 확정하고, 멀티모듈로 “한 레포, 여러 Spring Boot 앱” 구조를 설계합니다.
대규모 트래픽 처리와 시스템 확장성을 위한 핵심 기술인 ‘비동기 시스템’의 설계부터 구현까지 실무 관점에서 완벽하게 정리했습니다. 메시징 시스템(Kafka, RabbitMQ)을 활용한 비동기 아키텍처 설계와 메시지 유실 방지 전략, 그리고 데이터 정합성을 위한 트랜잭션 아웃박스 패턴 및 CDC(Change Data Capture) 기술을 깊이 있게 다룹니다. 더불어 Java 21+ 환경에서의 가상 스레드(Virtual Thread) 활용법과 주의사항까지, 백엔드 면접에서 차별화된 답변을 준비할 수 있는 핵심 지식을 담았습니다.
분산 시스템 환경, 특히 CQRS나 마이크로서비스 아키텍처에서 발생하는 ‘이중 쓰기(Dual Write)’ 문제를 해결하기 위한 패턴입니다. 비즈니스 데이터 처리와 메시지 발송을 하나의 데이터베이스 트랜잭션으로 묶어 원자성(Atomicity)을 보장합니다. DB에 ‘Outbox’라는 별도의 테이블을 두고, 이벤트를 먼저 저장한 뒤 별도의 프로세스가 이를 메시지 브로커로 전송하는 방식을 통해 메시지 유실 없는 ‘적어도 한 번(At-least-once)’ 전송을 보장합니다.