Consistency Availability Partition

CAP는 세 단어 암기가 아니라 네트워크 지연과 단절이 있을 때 정확한 응답, 가능한 응답, 명시적 실패 중 무엇을 선택할지 정하는 문제다.
일관성 선택은 DB 옵션이 아니라 사용자 경험, API 계약, retry, cache, replica, event 처리, 장애 격리를 함께 바꾸는 설계 판단이다.
모든 데이터에 강한 일관성을 요구하면 성능과 가용성이 떨어지고, 모든 데이터를 eventual로 두면 사용자는 방금 한 행동을 믿지 못한다.

Consistency는 사용자가 읽는 값이 어떤 기준으로 최신 또는 올바른지 정하는 것이다.
Availability는 문제가 있어도 응답을 줄지, 틀릴 수 있으면 실패시킬지 정하는 것이다.
Partition은 네트워크 단절만이 아니라 timeout, replica lag, 메시지 지연, region 간 불통처럼 조정이 어려운 상태를 포함한다.
주문, 결제, 재고, 권한은 강한 일관성이나 명시적 실패가 필요하다.
피드, 추천, 좋아요 수, 검색 색인은 지연 반영을 허용할 수 있지만 UX와 freshness 표시가 필요하다.
Read-after-write, monotonic read, conflict resolution은 “사용자가 납득 가능한 읽기 경험”을 만드는 실무 일관성 모델이다.

데이터별 실패 비용을 분류한다.
- 돈, 권한, 재고, 주문 상태는 틀리면 안 되는 영역인지 확인한다.
사용자 행동 직후 읽기 경험을 정한다.
- 방금 쓴 값은 반드시 보여야 하는지, 몇 초 지연을 허용하는지 정한다.
읽기 경로를 선택한다.
- primary, replica, cache, read model, client-local optimistic state 중 하나를 고른다.
네트워크와 메시지 실패를 가정한다.
- timeout, 중복 이벤트, 순서 뒤바뀜, replica lag, partial failure를 정상 시나리오로 둔다.
API 계약을 남긴다.
- pending, processing, stale, conflict, retryable 같은 상태를 응답에 드러낸다.
운영 지표를 붙인다.
- replica lag, stale read rate, conflict count, read-after-write miss, projection lag를 본다.

CAP를 “셋 중 둘만 고른다”로만 외우기 쉽다.
- 실무에서는 기능별로 어떤 실패 상황에서 어떤 응답을 줄지 정하는 것이 더 중요하다.
Strong consistency가 항상 좋은 선택이라고 느끼기 쉽다.
- 정확성은 높지만 primary 부하, latency, 장애 시 실패율, 운영 비용이 커진다.
Eventual consistency를 “언젠가 맞겠지”로 느슨하게 두기 쉽다.
- 지연 한계, conflict 처리, 사용자 안내, 재처리 절차가 없으면 장애와 데이터 불신으로 이어진다.
Replica read를 쓰면 자동으로 확장된다고 생각하기 쉽다.
- read-after-write가 필요한 화면은 primary read, version token, lag wait 같은 보정이 필요하다.

01. CAP를 실무 언어로 이해하기 상세.md: CAP를 기능별 응답 선택과 장애 시 계약으로 해석한다.
02. Strong Eventual Consistency 상세.md: 강한 일관성과 최종 일관성의 적용 기준과 비용을 비교한다.
03. Read-after-write와 Monotonic Read 상세.md: 사용자가 방금 쓴 값과 이전에 본 값이 뒤로 가지 않게 만드는 읽기 전략을 다룬다.
04. 분산 환경의 실패 모델 상세.md: timeout, partial failure, message delay, split brain을 설계 입력으로 다룬다.
05. 일관성 선택이 UX에 미치는 영향 상세.md: pending, stale, conflict, optimistic UI 같은 사용자 계약으로 일관성 선택을 연결한다.

확인 질문: 이 기능은 틀린 응답보다 실패가 더 나은가?
- 답변: 결제, 주문, 권한처럼 틀린 성공이 더 위험하면 명시적 실패나 강한 일관성을 택해야 한다.
확인 질문: 사용자가 방금 쓴 값은 어디서 읽어야 하는가?
- 답변: read-after-write가 필요하면 일정 시간 primary read, version 기반 replica wait, client-local 반영 중 하나를 정해야 한다.
확인 질문: eventual consistency를 허용하려면 무엇을 함께 설계해야 하는가?
- 답변: 지연 한계, stale 표시, conflict 처리, 재처리, projection lag 지표를 함께 설계해야 한다.

동블