좋아요 수는 잠깐 늦게 보여도 되지만 마지막 좌석을 두 사람에게 판매해서는 안 됩니다. 두 기능에 필요한 일관성을 어떤 기준으로 나누겠습니까?

일관성 강도는 중요도라는 말보다 사용자가 어떤 순서의 결과를 봐야 하는지와 잘못된 성공의 비용으로 정합니다. 좋아요 수는 잠시 늦어도 되지만 마지막 좌석 구매는 두 사람에게 동시에 성공하면 안 됩니다. 전자는 최종 일관성을 허용할 수 있고 후자는 선형화 가능한 확정 경계와 조건부 갱신이 필요합니다.

관찰 계약

최종 일관성은 변경이 멈추고 전달·복구가 진행되면 복제본이 수렴한다는 약속이지 일정 시간 내 수렴 보장은 아닙니다. 선형화 가능성(linearizability)은 각 연산이 호출과 응답 사이 한 시점에 일어난 것처럼 보이고 완료된 쓰기의 순서를 이후 읽기가 거스르지 않는 보장입니다.

좌석 화면의 잔여 수는 캐시나 지연 복제본을 쓸 수 있지만 구매 확정은 권위 저장소에서 remaining > 0 검사와 차감을 원자적으로 처리합니다. 단절로 최신 상태를 확인할 수 없으면 실패·보류로 돌립니다. 좋아요는 이벤트 합산과 잠정 표시를 허용할 수 있습니다.

기능별 비용

모든 조회를 선형화하면 지연과 가용성 비용이 커지므로 판단이 잘못되면 안 되는 경계를 보호합니다. read-your-writes·monotonic reads는 한 사용자의 관찰을 개선하는 약한 보장으로 전체 전역 순서를 요구하지 않을 수 있습니다. DB transaction 격리와 여러 서버의 선형화 가능성도 같은 말로 취급하지 않겠습니다.

검증은 동시 좌석 구매, 쓰기 직후 replica 읽기, 지역 단절·복구를 주입합니다. 중복 확정·초과 판매, 완료된 쓰기를 거스르는 읽기, 좋아요의 지연과 수렴을 분리 확인합니다. 기능별 관찰 계약이 저장소·라우팅·오류 응답 선택의 기준입니다.

호출과 응답의 이력으로 판정합니다

x가 0인 상태에서 쓰기 x=1이 성공 응답을 반환한 뒤 시작한 읽기가 0을 반환하면 선형화 가능성을 위반합니다. 쓰기와 읽기가 겹쳤다면 읽기를 쓰기 앞에 둘 수 있어 0이 허용될 수 있습니다. '가장 최근'이라는 말은 서버 벽시계가 큰 요청이 아니라 완료와 이후 호출 사이의 실시간 선후를 존중한다는 뜻입니다. timeout 쓰기는 적용됐을 수 있으므로 이력 검사에서도 단순 실패로 제외하지 않습니다.

개별 GET과 SET이 각각 선형화 가능해도 GET으로 재고를 읽고 애플리케이션에서 뺀 뒤 SET하는 복합 작업은 원자적이지 않습니다. 두 요청이 모두 1을 읽고 0을 쓰면 각각의 API는 올바른 순서로 실행됐어도 두 판매가 성공할 수 있습니다. 재고가 양수일 때만 감소시키는 하나의 조건부 명령이나 트랜잭션이 필요합니다.

여러 행의 트랜잭션이 직렬 실행과 같은 결과를 내는 직렬화 가능성과, 완료된 트랜잭션의 실제 시간 순서까지 존중하는 엄격한 직렬화 가능성도 구분합니다. 제품이 '강한 일관성'이라고 표현할 때 어느 읽기·쓰기·트랜잭션 범위의 약속인지 확인하고, UI의 잠정 조회와 확정 변경을 같은 단어로 묶지 않겠습니다.