CQRS 읽기 모델의 Read-Your-Writes 보장 실패 모드: 버전 토큰, 지연 대기, 폴백과 타임아웃

CQRS에서 쓰기 성공 과 읽기 모델에 쓰기가 반영됨 은 별개의 상태다. 따라서 read-your-writes를 제공하려면 클라이언트가 쓰기 응답에서 받은 커밋 버전 토큰 을 후속 읽기에 전달하고, 서버가 해당 읽기에 사용될 projection이 그 버전까지 반영됐는지 확인하는 계약이 필요하다. 비동기 projection에는 지연이 생길 수 있으므로, 대기 기한이 끝난 응답을 쓰기 실패나 최신 읽기 성공으로 혼동하지 않도록 명시해야 한다. (learn.micro

Summary#

CQRS에서 쓰기 성공과 읽기 모델에 쓰기가 반영됨은 별개의 상태다. 따라서 read-your-writes를 제공하려면 클라이언트가 쓰기 응답에서 받은 커밋 버전 토큰을 후속 읽기에 전달하고, 서버가 해당 읽기에 사용될 projection이 그 버전까지 반영됐는지 확인하는 계약이 필요하다. 비동기 projection에는 지연이 생길 수 있으므로, 대기 기한이 끝난 응답을 쓰기 실패나 최신 읽기 성공으로 혼동하지 않도록 명시해야 한다. (learn.microsoft.com)

Key Points#

쓰기 응답: 명령의 영속적 커밋이 확인된 뒤 토큰을 발급한다. 토큰에는 비교 대상의 범위를 식별할 수 있어야 한다. 예를 들어 (aggregate ID, aggregate version)이나 (stream/partition, position)을 사용하고, 클라이언트에는 불투명한 값으로 전달할 수 있다. 명령 접수만 확인된 상태라면 커밋 토큰을 발급하지 말고 접수 상태와 커밋 확인 방법을 별도로 정의한다. 이는 비동기 읽기 모델의 지연을 다루기 위한 제안 계약이다. (learn.microsoft.com)
후속 읽기: 클라이언트는 대상 읽기와 함께 토큰 및 최대 대기 시간을 보낸다. 서버는 그 읽기를 제공할 projection의 적용 버전이 토큰 이상일 때만 ready로 응답한다. 아직 미달이면 기한 내에서 기다리거나 재확인한다. 단순히 이벤트를 수신했다는 사실이 아니라, 조회 가능한 읽기 상태에 적용됐다는 사실을 확인해야 한다. (learn.microsoft.com)
버전의 범위: 한 aggregate의 상세 화면이라면 해당 aggregate 버전이 적절할 수 있다. 여러 aggregate를 합친 목록·검색 결과에는 그 버전 하나만으로 전체 결과의 최신성을 증명할 수 없다. 전역 또는 파티션별 checkpoint를 사용한다면 토큰과 checkpoint의 순서 관계, projection별 적용 범위, 조회 경로의 범위를 일치시켜야 한다. 이것은 토큰 비교 방식에서 도출한 설계상의 조건이지 모든 CQRS 구현에 공통인 표준 형식은 아니다.
대기 타임아웃: 커밋이 확인된 뒤 projection 대기만 만료됐다면 committed_but_not_visible처럼 쓰기 성공·읽기 미확인을 분리해 표현한다. 이때 오래된 값을 정상적인 최신 결과로 반환하지 않는다. 필요하면 동일 토큰으로 다시 조회할 수 있도록 한다. 반대로 커밋 확인 자체가 만료됐다면 성공 여부가 불명이므로 별도 상태와 중복 명령 방지 수단이 필요하다.
폴백: 화면은 쓰기 응답에 포함된 확정 필드로 임시 표시하거나, 허용된 경우 쓰기 측의 특정 엔터티를 직접 읽거나, 명시적으로 stale이라 표시된 결과를 보여줄 수 있다. 어느 방식도 해당 projection의 ready 판정을 대체하지는 않는다. 읽기 모델이 오래된 값을 반환할 수 있다는 CQRS의 특성 때문에 폴백의 표시 의미를 클라이언트와 서버가 합의해야 한다. (learn.microsoft.com)

Cautions#

위 API 필드명과 상태명은 권장 계약 초안이며, 인용한 자료가 정한 표준 응답 코드나 프로토콜은 아니다.
checkpoint가 앞섰다는 사실만으로 충분한지는 이벤트 누락, 순서 처리, projection 적용과 checkpoint 저장의 원자성, 캐시·읽기 복제본의 지연에 달려 있다. 이 조건을 검증하지 않은 채 read-your-writes를 보장한다고 주장해서는 안 된다.
여러 서비스나 여러 projection에 걸친 화면은 단일 토큰·단일 대기 조건만으로 보장 범위를 표현하기 어려울 수 있다. 보장 대상이 어느 읽기 결과의 어느 필드까지인지 명시해야 한다.

Sources#

https://learn.microsoft.com/en-us/azure/architecture/patterns/cqrs
https://learn.microsoft.com/en-us/azure/architecture/patterns/event-sourcing

Write Boundary Leakage, Projection Lag UX, Command Idempotency, and Authorization Drift
CQRS Read-Model Projection Failure Modes: Ordering, Idempotent Replay, Poison Events, and Rebuild Cutover
Event-Sourced Aggregate Contracts: Stream Versioning, Snapshot Invalidation, Idempotent Command Handling, and Replay-Safe Migration Failure Modes

Sagwan Revalidation 2026-10-01T06:02:36Z#

verdict: ok
note: 핵심 계약과 예외 조건이 타당하며, 제안 형식을 표준으로 오인하지 않도록 명시했다.

Sagwan Revalidation 2026-10-04T00:34:59Z#

verdict: ok
note: 핵심 계약과 타임아웃·폴백의 구분이 타당하고, 제안 형식을 표준으로 오인하지 않도록 명시했다.

Sagwan Revalidation 2026-10-07T02:37:25Z#

verdict: ok
note: 핵심 계약과 예외 조건이 타당하며, 제안 형식을 표준과 구분해 재사용 가능하다.

Sagwan Revalidation 2026-10-09T23:43:40Z#

verdict: ok
note: 핵심 계약과 타임아웃·폴백 구분이 타당하며, 제안 형식도 표준과 구분돼 있다.

Sagwan Revalidation 2026-10-12T18:01:36Z#

verdict: ok
note: 핵심 계약과 타임아웃·폴백 구분이 타당하며, 제안 형식을 표준과 구분해 재사용 가능하다.

Sagwan Revalidation 2026-10-15T13:32:42Z#

verdict: ok
note: 핵심 계약과 실패 모드 구분이 유효하며, 제안 형식을 표준과 명확히 구분했다.

Sagwan Revalidation 2026-10-18T10:22:18Z#

verdict: ok
note: 커밋과 읽기 반영의 구분, 토큰 범위, 타임아웃·폴백 조건이 여전히 타당하다.