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 실습 시리즈 2편에서는 1편에서 만든 멀티모듈/서비스 분리 구조를 로컬에서 실행 가능한 상태로 완성합니다. Docker로 MySQL/Redis를 띄우고, 3개 Spring Boot 앱을 8081/8082/8083 포트로 동시에 실행한 뒤 curl로 스모크 테스트를 수행해 다음 편(이벤트/프로젝션) 준비를 끝냅니다.
CQRS 실습 시리즈 1편에서는 주문/결제/주문내역 도메인을 대규모 트래픽 관점에서 바라보며, 쓰기(Command)와 읽기(Query)를 분리하는 목표와 기본 가정을 정리합니다. 이어서 order-command, payment-command, order-query로 서비스 경계를 확정하고, 멀티모듈로 “한 레포, 여러 Spring Boot 앱” 구조를 설계합니다.
CRUD 아키텍처의 성능 한계와 복잡성을 해결하기 위한 CQRS(명령 및 조회 책임 분리) 패턴을 Microsoft Azure 가이드를 기반으로 심층 분석합니다. 비즈니스 로직을 처리하는 ‘명령(Command)’ 모델과 화면 반환에 최적화된 ‘조회(Query)’ 모델을 분리하는 원리부터, 폴리글랏 저장소를 활용한 물리적 분리 전략, 그리고 이벤트 기반의 데이터 동기화와 최종 일관성(Eventual Consistency) 문제까지 실제 Java 코드 예제와 함께 다룹니다.
분산 시스템 환경, 특히 CQRS나 마이크로서비스 아키텍처에서 발생하는 ‘이중 쓰기(Dual Write)’ 문제를 해결하기 위한 패턴입니다. 비즈니스 데이터 처리와 메시지 발송을 하나의 데이터베이스 트랜잭션으로 묶어 원자성(Atomicity)을 보장합니다. DB에 ‘Outbox’라는 별도의 테이블을 두고, 이벤트를 먼저 저장한 뒤 별도의 프로세스가 이를 메시지 브로커로 전송하는 방식을 통해 메시지 유실 없는 ‘적어도 한 번(At-least-once)’ 전송을 보장합니다.