최종 일관성(eventual consistency)은 "지금 당장은 저장소마다 값이 다를 수 있지만, 새 변경이 멈추면 결국 같아진다"는 보장이다. 원본 DB와 검색 색인·캐시·다른 서비스처럼 물리적으로 분리된 저장소를 한 트랜잭션으로 묶을 수 없을 때 받아들이는 일관성 모델(consistency model)이다.
상품명 수정 → ① DB 반영(즉시) → ② 검색 색인 갱신(수백 ms~수 초 뒤)
①과 ② 사이: DB엔 새 이름, 검색엔 옛 이름BASE
분산 시스템과 NoSQL 쪽에서 ACID의 대비로 쓰는 말이다. Basically Available(기본적으로 가용), Soft state(상태가 바뀌는 중일 수 있음), Eventual consistency. 강한 일관성(strong consistency) 일부를 내주고 가용성과 확장성을 얻는다.
틈을 메우는 방법
| 문제 | 증상 | 대응 |
|---|---|---|
| 누락 | DB는 바뀌었는데 복사본은 그대로 | 재시도, 트랜잭셔널 아웃박스 패턴, CDC (변경 데이터 캡처) |
| 순서 꼬임 | "수정"이 "삭제"보다 늦게 도착 | 버전·타임스탬프 비교 후 오래된 것 무시 |
| 중복 | 같은 이벤트가 두 번 | 멱등성 처리 |
| 드리프트 | 조금씩 어긋남이 쌓임 | 주기적 전체 재동기화(재색인) |
마지막의 주기적 전체 재동기화는 거의 모든 검색 시스템이 안전망으로 둔다.
설계 질문
- 얼마나 늦어도 되나? 검색 결과가 1초 늦는 건 괜찮다. 재고·결제처럼 즉시성이 필요한 판단은 복사본이 아니라 원본을 조회한다
- 틀리면 얼마나 치명적인가? "재고 0인데 검색에 보임"은 주문 단계에서 원본을 다시 확인하도록 설계한다
읽기 복제본의 복제 지연(replication lag)도 같은 성격이다. 여러 사람이 동시에 편집하는 협업 도구는 CRDT처럼 충돌 없이 수렴하는 자료구조로 이 문제를 푼다. 확장할수록 마주치는 선택은 사용자 수에 따른 규모 확장에서 볼 수 있다.