여러 서버, 한 테이블: 주문 계층의 충돌 해결

안탈리아 벨렉의 1200석 규모 연회장에서 서버 4명이 같은 20인 원형 테이블에 동시에 메뉴를 추가합니다. 전통적인 "last-write-wins"는 14개의 항목을 조용히 덮어씁니다. 본 글은 낙관적 락, 409 Conflict, 재시도 패턴을 프로덕션에 적용한 방법을 소개합니다.

last-write-wins가 부족한 이유

단순한 UPDATE orders SET items = ? WHERE id = ?는 마지막 커밋만 남깁니다. 200ms 안에 4개의 POST가 들어오면 주방엔 20개 중 6개만 전달됩니다.

해결책은 행마다 version 컬럼을 두는 것. 클라이언트는 열 때 읽고 저장할 때 함께 보내며, 서버가 원자적으로 검증합니다.

버전 기반 낙관적 락

version INTEGER, updated_at을 추가합니다. PATCH 흐름:

• 클라이언트: { items, expected_version: 7 }.
• 서버: UPDATE ... WHERE id = ? AND version = 7.
• 0행 영향 → 409 Conflict + 현재 상태.

409 Conflict + 클라이언트 머지

자동 재시도는 없습니다. 클라이언트는 최신 주문을 보여주고 변경 항목을 강조하며 확인을 받습니다. 벨렉에서는 체감 충돌률이 0.4%에서 0%로 떨어졌습니다.

append-only 로그 order_events까지 두면 감사가 쉬워집니다.

FAQ

SELECT FOR UPDATE는? 서버를 직렬화해 처리량을 떨어뜨립니다.

D1에서 동작? 네, INTEGER 원자 UPDATE는 안전합니다.

오프라인은? 로컬 큐 + expected_version, 재연결 시 머지 UI.

도움이 되셨나요? 공유해 주세요.