슬롯 중복 예약 방지를 애플리케이션 락이나 SELECT ... FOR UPDATE가 아니라 PostgreSQL의 EXCLUDE USING gist (resource_id WITH =, seat_no WITH =, during WITH &&) 배타 제약으로 DB에 맡겼다. 좌석은 capacity만큼 행으로 분해해 넣고, 홀드→예약 승격은 두 문장이 아니라 UPDATE 한 문장으로 처리했다.
대안비관적 락(SELECT ... FOR UPDATE)으로 리소스 행을 잡고 애플리케이션에서 겹침을 계산하는 방식, 또는 Redis 분산 락.근거중복 예약은 오프라인에서 고객 두 명이 같은 시간에 오는 사고가 되므로 애플리케이션 로직이 아니라 DB 불변식으로 막아야 한다. 승격을 UPDATE 한 문장으로 둔 이유는, 배타 제약의 대상 상태 목록에 HELD와 CONFIRMED가 둘 다 있어서 점유 집합이 바뀌지 않기 때문이다 — '홀드 만료 + 예약 INSERT' 두 문장으로 짜면 그 틈에 남이 가져가는데, 그때는 이미 PG 승인이 끝나 되돌릴 수 없다.비용배타 제약은 즉시 거부가 아니라 블로킹한다 — 충돌 상대가 커밋/롤백할 때까지 기다린다(실측: 상대가 5초 뒤 커밋하면 4초 대기 후 거부). 그래서 모든 요청이 같은 좌석을 먼저 노리면 사실상 직렬화되고 커넥션 풀이 대기 스레드로 가득 찬다. 시작 좌석 무작위 분산과
lock_timeout을 함께 넣어야 했다. 또 실패한 INSERT가 트랜잭션 전체를 죽이므로(current transaction is aborted) '실패하면 다음 좌석' 루프를 한 트랜잭션 안에서 짤 수 없어 시도마다 새 트랜잭션을 여는 구조가 됐다. 그리고 락 대기 초과(55P03)는 '찼다'가 아니라 '모른다'인데, 이를 만석으로 뭉개면 정원이 남았는데 409가 나가는 오판이 생긴다.