관측

API 호출이 성공했다고 해서 업무 상태, 감사 이력, 프로젝션이 계속 일치하는 것은 아닙니다. 각 경계의 신호를 따로 모으고 같은 식별자로 연결해야 합니다.

수집할 신호

저장소 종류와 애그리거트 유형별 JaVers 커밋 지연과 실패
코덱의 인코딩·디코딩 실패, 커밋 ID, GlobalId, 스냅샷 버전
Exposed 트랜잭션 오류, 고유 키 충돌, 테이블 증가량, 넓은 조회의 지연
Redis 명령 지연, 키 수, 메모리와 캐시 축출, 영속성 상태, 복제 지연
Kafka 전송 지연과 시간 초과, 프로듀서 오류, 토픽과 파티션, 소비자 지연, 재시도와 데드 레터, 프로젝션 실패
정기 정합성 점검에서 찾은 도메인-감사, 도메인-프로젝션 불일치 수

AbstractCdoSnapshotRepository.getAll()은 모든 키와 스냅샷을 읽고 정렬한 뒤 조건을 적용합니다. 키가 10,000개를 넘었다는 경고는 단순한 로그 소음이 아니라 조회 방식을 다시 살펴보라는 신호입니다. Kafka 저장소의 읽기 메서드도 지원하지 않는 경로가 호출될 때마다 경고를 남깁니다. 통합 테스트에서 이 경고를 잡으면 저장 역할을 잘못 고른 경우를 일찍 찾을 수 있습니다.

불일치 확인

애플리케이션 애그리거트 ID 하나를 골라 최신 감사 스냅샷과 예상 업무 버전 또는 필드를 비교합니다. 이어서 Redis의 최신 이벤트나 프로젝션 버전을 비교합니다. 차이가 나면 도메인-감사, 감사-발행, 소비자 지연, 프로젝션 적용 가운데 어디서 끊겼는지 분류하세요. 민감한 전체 페이로드를 메트릭 레이블에 넣지 말고, 상세 증거는 접근이 통제된 진단 로그에 남깁니다.

예제 소비자는 Kafka에서 읽은 순서대로 이벤트를 적용하고 같은 키의 순서를 기대하지만, 지연 메트릭과 오프셋 관리는 제공하지 않습니다. 운영 구성에서 따로 추가해야 합니다. 소스는 OrderProjectionEventConsumer.kt입니다.