요청 생애주기 기준

동시성 문제는 강한 옵션 하나보다, 공유 데이터에 닿는 순서를 어떻게 설계하느냐로 더 잘 예방됩니다.

핵심은 원칙 5개를 따로 외우는 것이 아니라, 충돌을 줄이는 단계와 남은 충돌을 회복하는 단계를 요청 흐름에 맞춰 배치하는 것입니다.

시점
설계 규칙
왜 중요한가
1
공유 자원에 닿기 전
시작 전에 잠금 시간과 병목부터 줄입니다.
트랜잭션을 짧게 유지 입력 대기와 외부 API 호출은 트랜잭션 밖으로 분리합니다.
격리 수준은 필요한 만큼만 습관적으로 SERIALIZABLE로 올리지 말고 요구사항에 맞춥니다.
대기열이 커지기 전에 충돌 면적을 줄입니다.

불필요하게 오래 잡히는 잠금과 과한 검증 비용을 먼저 제거합니다.

2
실제로 상태를 바꿀 때
같은 규칙으로 접근해야 충돌 결과가 예측 가능합니다.
잠금 순서를 항상 고정 A -> B처럼 자원 획득 순서를 통일해 데드락 가능성을 낮춥니다.
원자적 SQL을 우선 사용 UPDATE balance = balance - N으로 읽기-계산-쓰기를 한 연산으로 묶습니다.
데드락과 갱신 분실을 예방합니다.

상태 변경 순간의 경쟁 조건을 사람 손의 순서가 아니라 DB 규칙으로 제어합니다.

3
충돌이 남았을 때
예방으로 다 막지 못한 실패만 좁게 복구합니다.
자동 재시도는 제한적으로 데드락과 낙관적 잠금 실패는 backoff와 최대 횟수로만 다시 시도합니다.
일시 충돌은 회복하고 무한 반복은 막습니다.

운영 장애를 줄이되, 끝없는 재시도로 시스템을 더 불안정하게 만들지 않습니다.

핵심

순서를 기억하면 쉽습니다. 먼저 줄이고, 갱신 순간의 규칙을 고정하고, 마지막에 제한적으로 재시도합니다.