예약 시스템에서 어떻게 중복 예약을 방지할까?

숙소 예약시 중복 예약 문제

온라인 예약 시스템에서는 “더블 부킹(Double Booking)”이 언제나 큰 고민거리입니다.
같은 숙소를 동시에 여러 사용자가 예약하려고 시도할 때, 제대로 제어하지 않으면 한 자리에도 두 명 이상의 예약이 생성될 수 있습니다. 동시성 문제가 발생하면 더블 부킹(Double Booking)과 같은 심각한 오류가 발생할 수 있습니다. 이는 단순히 사용자 불편을 넘어 서비스 신뢰도를 무너뜨리는 치명적인 문제로 이어집니다.

하지만 중복 예약 문제는 단순히 SQL 쿼리만 잘 짠다고 해결되지 않습니다.
왜냐하면 여러 사용자의 요청이 거의 동시에 들어오면, 각 요청이 독립적으로 DB를 읽고 쓰면서 충돌이 발생할 수 있기 때문입니다. 따라서 데이터베이스 트랜잭션, 락(Lock), 격리 수준(Isolation Level) 등 다양한 동시성 제어 전략을 함께 고민해야 합니다.

이번 글에서는 예약 시스템에서 중복 예약을 방지하기 위한 동시성 제어 전략을 단계별로 살펴보고, 실제 구현 사례와 PostgreSQL을 활용한 안전한 예약 처리 방법까지 다루겠습니다.

---

목차

1. 중복 예약 문제의 이해
   • 더블 부킹이 발생하는 시나리오 소개
   • 단순 쿼리로 처리할 때 발생할 수 있는 동시성 문제 예시
2. 동시성 제어 기법 소개
   • 트랜잭션(Transaction)과 격리 수준(Isolation Level)
   • 비관적 락(Pessimistic Lock, SELECT … FOR UPDATE)
   • 낙관적 락(Optimistic Lock, Version/UpdatedAt 필드 활용)
   • DB 레벨 제약 조건 (Unique, EXCLUDE Constraint 등)
3. PostgreSQL 기반 구현 사례
   • 예약 테이블 설계와 제약 조건
   • 트랜잭션 + FOR UPDATE를 활용한 안전한 예약 처리
   • 동시성 테스트 예시 및 시나리오
4. 장단점 및 실제 적용 전략
   • 비관적 락 vs 낙관적 락
   • 트랜잭션 격리 수준과 성능 고려
   • 서비스 규모, 트래픽 패턴에 따른 선택 가이드
5. 정리 및 결론
   • 중복 예약 방지를 위한 핵심 포인트 요약
   • 동시성 제어를 잘 설계해야 하는 이유 강조

---

중복 예약 동시성 문제(Race Condition)

더블 부킹 시나리오

예를 들어, 같은 숙소 A에 12월 1일부터 12월 5일까지 예약을 하고 싶어 하는 두 사용자가 있다고 가정해봅시다.

만약 이 과정에서 DB가 요청 간의 동시성을 제어하지 않으면,

시간 →
[사용자 1] 예약 가능 여부 조회 (OK)
[사용자 2] 예약 가능 여부 조회 (OK)  ← 아직 A의 예약이 DB에 반영되지 않음
[사용자 1] 예약 생성 (SUCCESS)
[사용자 2] 예약 생성 (SUCCESS)  ← 더블 부킹 발생!

두 명의 사용자(1, 2)가 동일한 숙소, 동일한 기간을 동시에 예약하려는 경우 사용자 1이 예약 가능 여부를 조회하고 생성하기 직전에 사용자 2가 그 사이에 껴들어 예약 가능 여부 조회를 할 수 있고 사용자 2는 사용자 1이 이미 해당 날짜에 예약을 생성할 예정이라는 것도 모른채 중복 예약을 초래하게 됩니다.

아래 /reservation 의 비즈니스 로직을 처리하는 서비스 단의 코드를 살펴보면

숙소 예약은 1) 중복 예약 조회 2) 예약 생성 두 단계로 이루어져 있다는 사실을 알 수 있습니다.

  /**
   * ❌ 트랜잭션 없는 예약 생성 (더블 부킹 발생 가능)
   *
   * 문제점:
   * 1. 조회와 생성 사이에 Race Condition 발생
   * 2. 동시 요청 시 두 요청 모두 "예약 없음"으로 판단
   * 3. 결과: 더블 부킹 발생
   *
   */
  async createWithoutTransaction(
    createReservationDto: CreateReservationDto,
  ): Promise<Reservation> {
    // 날짜 유효성 검증
    this.validateDates(
      createReservationDto.check_in,
      createReservationDto.check_out,
    );

    this.logger.log(
      `Checking availability for accommodation ${createReservationDto.accommodation_id}`,
    );

    // Step 1: 중복 예약 조회 (락 없음)
    const overlap = await this.reservationRepository
      .createQueryBuilder('r')
      .where('r.accommodation_id = :accommodationId', {
        accommodationId: createReservationDto.accommodation_id,
      })
      .andWhere('r.status != :cancelled', {
        cancelled: ReservationStatus.CANCELLED,
      })
      .andWhere('(r.check_in < :checkOut AND r.check_out > :checkIn)', {
        checkIn: createReservationDto.check_in,
        checkOut: createReservationDto.check_out,
      })
      // ❌ 락이 없음! 여기서 Race Condition 발생
      .getOne();

    if (overlap) {
      throw new ConflictException('해당 기간에 이미 예약이 존재합니다.');
    }

    // ⚠️ 문제: 위 조회와 아래 생성 사이에 다른 요청이 끼어들 수 있음!
    // 시나리오:
    // T1: 사용자 A 조회 → 예약 없음
    // T2: 사용자 B 조회 → 예약 없음 (A가 아직 생성 전)
    // T3: 사용자 A 생성 → 성공
    // T4: 사용자 B 생성 → 성공 (더블 부킹!)

    // Step 2: 예약 생성
    const reservation = this.reservationRepository.create({
      ...createReservationDto,
      status: ReservationStatus.PENDING,
      created_at: new Date(),
    });

    const saved = await this.reservationRepository.save(reservation);

    this.logger.log(`Reservation created (ID: ${saved.id}) - NO TRANSACTION`);

    return saved;
  }

Race Condition 의 원인

이러한 더블 부킹(Race Condition)이 발생하는 본질적인 원인은 무엇일까요?

우선, 첫번째는 숙소 예약이 '원자적' 인 작업 단위가 아니기 때문입니다.
다시 말해, 숙소 예약 = 숙소 조회 + 생성 이라는 여러개의 작업으로 이루어져 있기 때문에,
작업 사이에 다른 트랜잭션이 껴들어갈 여지를 주는 것이 첫번째 문제라고 볼 수 있습니다.

만약 숙소 예약이 atomic 한 하나의 연산으로 이루어져 있었다면, 동시성 문제가 발생하지 않았을 것입니다.

💡 *숙소 예약 = 숙소 조회 + 생성 을 하나로 묶어서 원자적인 연산으로 처리 할 수 있다면, Race Condition 문제를 해결하지 않을까? *
원자적이라는 것은 한 작업이 시작되면 중간에 다른 작업이 끼어들 수 없고, 끝날 때까지 완전히 완료되어야 한다는 뜻입니다. 그렇게 되면 그 사이에 다른 작업이 끼어들어갈 수 있는 틈을 주지 않게 되므로 Race Condition 문제가 발생하는 원천을 차단합니다. 하지만 현실적으로 DB에 여러 쿼리를 날리는 경우, 단일 쿼리처럼 완전히 원자적으로 실행되도록 보장하는 방법은 제한적입니다. 뒤에 나올 트랜잭션을 사용하면 어느 정도 원자성을 확보할 수 있지만, 여전히 격리 수준, 락 전략, DB 제약 조건 등에 따라 동시성 문제를 완전히 차단할 수 있는지는 달라집니다. 트랜잭션은 원자적 연산이 아닌 여러개의 작업 단위를 한데 묶어 all or nothing 을 실현하는데 초점이 맞추어져 있으며, 실제 물리적인 의미의 원자적 연산이 아니라 '원자성' 이라는 특징을 만족할 수 있도록 처리하는 일종의 trick 입니다.

즉, “원자적 연산”이라는 개념은 아이디어상 완벽한 해결책이지만, 실제 시스템에서는 트랜잭션, 비관적/낙관적 락, DB 제약 조건 등과 함께 적용해야 Race Condition을 효과적으로 방지할 수 있습니다.

두번째는, 동일한 리소스에 대해 동시 접근을 제어하지 않았기 때문입니다.

---

동시성 제어 기법 소개

따라서 이러한 중복 예약을 막기 위해 사용할 수 있는 동시성 제어 방법은 크게 다음과 같습니다.

• 트랜잭션(Transaction) 과 격리 수준(Isolation Level)
• 비관적 락(Pessimistic Lock, SELECT … FOR UPDATE)
• 낙관적 락(Optimistic Lock, Version/UpdatedAt 필드 활용)
• DB 레벨 제약 조건 (Unique, EXCLUDE Constraint 등)

각 방식은 조금 다른 원리로 Race Condition 문제를 해결합니다. 앞으로 네가지 방식에 대해 하나씩 소개하겠습니다.

---

트랜잭션(Transaction)과 격리 수준(Isolation Level)

첫번째 방식은 트랜잭션(Transaction)과 격리 수준(Isolation Level)을 활용해서 동시성 제어를 하는 방법입니다. 트랜잭션을 사용하면 여러 쿼리를 하나의 단위로 묶어 원자성(Atomicity) 을 보장할 수 있습니다. 또한, 격리 수준을 조정하면 다른 트랜잭션과의 간섭을 어느 정도 제어할 수 있습니다.
예: READ COMMITTED, SERIALIZABLE

트랜잭션이란?

트랜잭션은 데이터베이스에서 수행되는 논리적 작업 단위 로, 여러 개의 SQL 문을 하나의 원자적(atomic) 단위로 묶어 실행합니다.

ACID 속성

• Atomicity (원자성): 트랜잭션 내 모든 작업이 완전히 성공하거나, 완전히 실패해야 함
• Consistency (일관성): 트랜잭션 실행 전후로 데이터베이스가 일관된 상태를 유지
• Isolation (격리성): 동시에 실행되는 트랜잭션들이 서로 영향을 주지 않음
• Durability (지속성): 커밋된 트랜잭션의 결과는 영구적으로 저장됨

예약 시스템에서의 중요성

예약 시스템에서는 다음과 같은 작업이 원자적으로 수행되어야 합니다.

1. 해당 기간에 예약이 있는지 확인
2. 없으면 예약 생성

  /**
   * 트랜잭션 기반 예약 생성 
   */
  async create(createReservationDto: CreateReservationDto): Promise<Reservation> {
    // 날짜 유효성 검증
    this.validateDates(createReservationDto.check_in, createReservationDto.check_out);

    const queryRunner = this.dataSource.createQueryRunner();
    await queryRunner.connect();
    await queryRunner.startTransaction('READ COMMITTED');

    const startTime = Date.now();

    try {
      // Step 1: 중복 예약 조회 + 비관적 락 (FOR UPDATE)
      this.logger.log(
        `Checking availability for accommodation ${createReservationDto.accommodation_id} ` +
        `from ${createReservationDto.check_in} to ${createReservationDto.check_out}`,
      );

      const overlap = await this.checkOverlapWithLock(queryRunner, createReservationDto);

      if (overlap) {
        throw new ConflictException(
          `해당 기간(${createReservationDto.check_in} ~ ${createReservationDto.check_out})에 이미 예약이 존재합니다. ` +
          `예약 ID: ${overlap.id}`,
        );
      }

      // Step 2: 예약 생성
      const reservation = queryRunner.manager.create(Reservation, {
        ...createReservationDto,
        status: ReservationStatus.PENDING,
        created_at: new Date(),
      });

      const saved = await queryRunner.manager.save(Reservation, reservation);

      // Step 3: 커밋
      await queryRunner.commitTransaction();

      const duration = Date.now() - startTime;
      this.logger.log(`Reservation created successfully (ID: ${saved.id}) in ${duration}ms`);

      if (duration > 1000) {
        this.logger.warn(`Slow transaction detected: ${duration}ms`);
      }

      return saved;
    } catch (error) {
      // 롤백
      await queryRunner.rollbackTransaction();

      this.logger.error(
        `Reservation failed for accommodation ${createReservationDto.accommodation_id}: ${error.message}`,
        error.stack,
      );

      throw error;
    } finally {
      // 연결 해제
      await queryRunner.release();
    }
  }

  /**
   * 날짜 유효성 검증
   */
  private validateDates(checkIn: string, checkOut: string): void {
    const checkInDate = new Date(checkIn);
    const checkOutDate = new Date(checkOut);
    const today = new Date();
    today.setHours(0, 0, 0, 0);

    if (checkInDate < today) {
      throw new BadRequestException('체크인 날짜는 오늘 이후여야 합니다');
    }

    if (checkOutDate <= checkInDate) {
      throw new BadRequestException('체크아웃 날짜는 체크인 날짜 이후여야 합니다');
    }

    // 최대 예약 기간 제한 (예: 30일)
    const diffDays = Math.ceil(
      (checkOutDate.getTime() - checkInDate.getTime()) / (1000 * 60 * 60 * 24),
    );

    if (diffDays > 30) {
      throw new BadRequestException('최대 30일까지 예약 가능합니다');
    }
  }

그러나 트랜잭션을 통해 1~2를 원자적으로 처리했다고 하더라도 여전히 Race Condition 문제가 발생합니다. 그 이유는 트랜잭션 사이에 다른 트랜잭션이 동시에 실행될 수 있기 때문입니다.

• Non-atomic Read-Modify-Write: 읽기와 쓰기 사이에 다른 트랜잭션이 끼어들 수 있음
• 격리 수준 부족: 트랜잭션이 다른 트랜잭션의 미커밋 데이터를 보지 못함
• 락(Lock) 부재: 동일한 리소스에 대해 동시 접근을 제어하지 않음

많은 사람들이 가지고 있는 흔한 오해 중 하나는 '트랜잭션' 이 배타적으로 실행된다고 생각하는 점입니다. 하지만 이는 트랜잭션 격리 레벨 수준에 따라 다릅니다. 따라서 트랜잭션을 사용하더라도 배타적 처리를 보장하지 않으며 동시에 실행될 수 있다는 사실에 유의해야합니다.

트랜잭션 격리 수준(Isolation Level)

PostgreSQL은 4가지 격리 수준을 제공합니다.

격리 수준	Dirty Read	Non-Repeatable Read	Phantom Read	설명
READ UNCOMMITTED	O	O	O	커밋되지 않은 데이터도 읽을 수 있음 (PostgreSQL 미지원)
READ COMMITTED	X	O	O	커밋된 데이터만 읽음 (PostgreSQL 기본값)
REPEATABLE READ	X	X	O	동일 트랜잭션 내에서 반복 읽기 시 동일한 결과 보장
SERIALIZABLE	X	X	X	완전한 직렬화, 가장 안전하지만 성능 저하 가능

만약 격리 수준을 SERIALIZABLE로 설정한다면 모든 트랜잭션은 항상 배타적으로 실행된다는 것을 보장할 수 있겠지만, 그외의 READ UNCOMMITTED나 READ COMMITTED 로 설정하면, 하나의 트랜잭션 내부에서도 다른 트랜잭션에서 진행 중인 작업도 읽을 수 있게 됩니다. 즉, 하나의 작업 내에서도 다른 트랜잭션이 끼어들어 현재 트랜잭션에 영향을 줄 수 있게 된다는 의미입니다.

따라서 트랜잭션을 걸고 격리 수준을 SERIALIZABLE로 설정하면 완전한 직렬화를 보장하므로 동시성 문제를 해결할 수 있습니다. 하지만 이 방법은 모든 작업을 순차적으로 처리하므로 동시 처리 성능이 크게 떨어진다는 큰 단점이 있습니다. 즉, 격리 수준을 높이면 데이터의 일관성은 높아지지만, 그와 동시에 병렬 처리 성능은 떨어지는 트레이드 오프 관계에 있습니다.

하지만 실상 동시성 제어가 필요한 부분은 '숙소 예약' 뿐인데,
SERIALIZABLE로 설정해서 모든 DB 연산을 직렬화해서 처리하는 건 무엇인가 손해를 보는 느낌이 듭니다.

따라서 일반적으로는 트랜잭션 격리 수준을 가능한 한 낮게 유지하면서 특정한 상황과 조건에 대해서만 동시성 처리를 해주는 것이 처리 성능 측면에서 좋은 선택일 수 있습니다.

참고

MySQL의 락 종류는 크게 글로벌 락, 테이블 락, 네임드 락, 메타데이터 락 등과 같은 엔진 레벨의 락과 공유 락(S-LOCK), 배타 락(X-LOCK) 등과 같은 트랜잭션 레벨의 락으로 나눌 수 있습니다.

참고

트랜잭션 레벨의 락을 활용하면 DB 전체에 격리 수준을 건들지 않고 특정 트랜잭션에 대해서만 lock 을 걸 수 있습니다.

행 수준 잠금

비관적 락(Pessimistic Lock)

비관적 락(Pessimistic Lock)에는 대표적으로 두 가지가 있습니다.

• 공유 잠금(Shared Lock, S-LOCK): 데이터를 읽을 때 사용되며, 여러 트랜잭션이 동시에 접근하여 읽을 수 있지만, 동시에 수정할 수는 없습니다.
  ex) 은행 시스템에서 고객의 잔액을 단순히 조회만 할 때, 동시에 여러 직원이 조회해도 되지만, 수정(입출금)은 하나만 해야 함
• 배타 잠금(Exclusive Lock, X-LOCK): 데이터를 수정할 때 사용되며, 오직 하나의 트랜잭션만 접근을 허용합니다. 다른 잠금(공유 포함)을 모두 차단합니다.
  ex) ATM에서 한 고객의 잔액을 수정(출금)할 때, 동시에 다른 곳에서 그 고객의 잔액을 읽거나 수정하지 못하게 해야 함.

구분	락 종류	다른 트랜잭션의 읽기 허용	다른 트랜잭션의 쓰기 허용	대표 구문
공유 잠금	S-Lock	✅ 가능	❌ 불가	SELECT ... LOCK IN SHARE MODE
배타 잠금	X-Lock	❌ 불가	❌ 불가	SELECT ... FOR UPDATE

다른 중복 예약 방지 글을 보면 주로 SELECT … FOR UPDATE 를 많이 사용해서 문제를 해결하는데
본래 SELECT … FOR UPDATE 는 단순 조회가 아니라 잠재적으로 수정(write)할 행을 확보하기 위해 사용되는 문법입니다.
SELECT … FOR UPDATE 는 항상 트랜잭션 안에서 사용해야합니다. SELECT … FOR UPDATE 를 쓰면, 조회 시점부터 트랜잭션 커밋까지 다른 트랜잭션이 같은 행에 접근하거나 수정 하지 못하게 됩니다.

근데 여기서 의문이 든건, SELECT … FOR UPDATE는 결국 현재 트랜잭션 내에서 변경(FOR UPDATE)을 위해 다른 트랜잭션은 수정하지 못하게 write 를 위해 lock 을 거는 문법 인 것 같았습니다.

그런데 결국 중복 예약을 방지하기 위해서는 read에 배타적 Lock 을 거는 것이 핵심입니다. 따라서

SELECT ... FOR UPDATE 가 write 뿐만 아니라 read 에도 배타적 lock 을 걸어주는지 확인할 필요가 있었습니다.

여러글을 찾아보았는데 SELECT ... FOR UPDATE 는 일반적으로는 Exclusive Lock 처럼 동작한다고 설명하는 글들이 많았으나, 일부 글에서는 읽기 자체에 대해서는 배타적으로 lock 을 걸어주지는 않는다고 설명했습니다.

그래서 실험을 직접 설계해보았습니다. 그 결과 PostgreSQL 에서 SELECT FOR UPDATE 구문은 Shared Lock 처럼 동작하는 것을 확인할 수 있었습니다.

또한, https://www.postgresql.org/docs/current/transaction-iso.html 공식 문서에서 SELECT FOR UPDATE 의 구체적인 동작을 확인할 수 있었습니다.

읽기 전용 트랜잭션에는 직렬화 충돌이 발생하지 않는다.
행 수준 잠금은 데이터 쿼리에는 영향을 미치지 않으며, 동일한 행에 대한 쓰기(writer)와 잠금(locker) 만 차단합니다.

또한, PostgreSQL 에서 SELECT FOR UPDATE 구문의 동작방식 에서 select for update 구문은 트랜잭션 격리레벨에 따라서 다르게 동작한다는 사실을 알았습니다. 여기서도

Read committed 와 Repeatable Read는
A 트랜잭션이 select for update 로 행을 잠그더라도 B 트랜잭션에서 데이터를 읽을 수 있다고 말합니다.

즉, PostgreSQL에서 SELECT … FOR UPDATE 는 Exclusive Lock(X-Lock)을 걸지만, MVCC 덕분에 다른 트랜잭션의 단순 SELECT는 블로킹하지 않습니다.

처음에는 SELECT … FOR UPDATE 를 사용하면 write lock을 거는 것과 동시에 read에도 lock 이 걸리므로, 조회 시점부터 트랜잭션 커밋까지 다른 트랜잭션이 같은 행에 접근하거나 수정 하지 못할 것 이라고 생각했는데, 잘못 알고 있었다는 사실을 깨달았습니다. 이때 걸리는 락은 현재 트랜잭션이 해당 행을 수정할 것이라는 전제하에 다른 트랜잭션의 쓰기(write) 접근을 막는 것입니다. 다른 트랜잭션에서 단순 읽기(SELECT만 하는 경우)는 막히지 않습니다. 즉, read는 허용되지만, 다른 트랜잭션에서 FOR UPDATE 또는 UPDATE/DELETE 같은 write 시도만 대기합니다. 따라서 아쉽게도 read 에 배타적 lock 을 걸어야 하는 현재 문제 상황에서는 SELECT … FOR UPDATE 가 동시성 문제를 해결해주지 못합니다.

또한, 이 쿼리가 실제로 락을 거는 대상은 "조회된 행들" 뿐 이라는 문제점도 있었습니다.
만약 “조회 결과가 비어 있다면”, 즉 아직 예약된 행이 없으면 락이 걸리지 않습니다. 이 때문에 SELECT … FOR UPDATE는 “경쟁 데이터가 이미 존재하는 상황”에서는 유효하지만,
“아직 첫 예약이 만들어지기 전” 상황에서는 무력합니다.

그 결과, 트랜잭션 수준의 락인 SELECT FOR UPDATE 로는 현재 상황에서 완벽하게 동시성(Race Condition) 문제를 해결할 수 없다고 판단하게 되었습니다.

---

Explicit Locking

그렇다면 읽기 자체에 배타적인 lock 을 걸려면 SELECT FOR UPDATE 말고 뭘 활용해야하지?

고민을 하다가, PostgreSQL 에서 Explicit Locking 을 제공해주는 것을 확인할 수 있었습니다.

PostgreSQL은 테이블 데이터에 대한 동시 접근을 제어하기 위해 다양한 잠금 모드를 제공합니다. 이러한 모드는 MVCC가 원하는 동작을 제공하지 않는 상황에서 애플리케이션 제어 잠금에 사용될 수 있습니다.

13.3.1. 테이블 수준 잠금
13.3.2. 행 수준 잠금
13.3.3. 페이지 수준 잠금
13.3.4. 교착 상태
13.3.5. 권고 잠금

그리고 공식 문서 중앙에 다음과 같이 Tip 을 명시한 것을 확인할 수 있었습니다.

“Only an ACCESS EXCLUSIVE lock blocks a SELECT (without FOR UPDATE/SHARE) statement.”

즉 이를 요약하면, 일반적인 SELECT 쿼리(단순 읽기)는 웬만한 락에도 막히지 않으며, 오직 가장 강력한 락(ACCESS EXCLUSIVE)이 걸려 있을 때만 SELECT도 막힌다는 의미입니다.

LOCK TABLE ~ IN ACCESS EXCLUSIVE MODE

따라서 LOCK TABLE reservations IN ACCESS EXCLUSIVE MODE 를 활용하여 테이블 단위로
해당 테이블에 접근하려는 모든 다른 트랜잭션을 차단할 수 있습니다.

• 다른 트랜잭션은 SELECT, INSERT, UPDATE, DELETE를 전혀 수행할 수 없습니다.
• 나중에 들어오는 SELECT조차도 락이 해제될 때까지 대기 상태에 들어갑니다.

reservations 테이블을 사용할 때 배타적 lock 을 거는 방식으로 본 문제 상황을 해결할 수는 있겠지만,
사실상 병렬 처리가 가능한 서로 다른 숙소와 서로 다른 날짜의 예약에 대해서도 배타적 lock 을 거는거라
성능이 떨어질 것을 우려하여 더 나은 방식이 없을지 고민을 하게 되었습니다. ( 그런데 우선 제 의견으로는 숙소 예약이 발생하는 빈도가 중요할 것 같은데 1초 안에 수번 예약이 발생할 수 있는 상황인지에 대해서 먼저 판단하고 그렇다면 더 낮은 격리 수준으로 동시 처리 성능을 높이는 방식을 고민해볼 것 같습니다. )

BEGIN;

LOCK TABLE reservations IN ACCESS EXCLUSIVE MODE;

-- 이제 이 테이블에 대해 SELECT, INSERT, UPDATE, DELETE 등 모든 접근이 차단됨
SELECT * FROM reservations; -- 가능 (현재 트랜잭션만)
UPDATE reservations SET status = 'CANCELLED'; -- 가능 (현재 트랜잭션만)

COMMIT;

애플리케이션 레벨 락(Application-Level Lock) : Advisory Locks

PostgreSQL에서는 일반적인 테이블/행 기반 락 외에도 애플리케이션이 정의한 의미를 가진 락을 걸 수 있습니다.

Advisory Lock은 PostgreSQL에서 “내가 정의한 의미로 임시 배타적 락을 거는 방법”입니다.

즉, 다른 트랜잭션이 같은 lock ID를 요청하면 block되지만, 애플리케이션이 그 lock을 준수하는 방법입니다.
Advisory Lock은 PostgreSQL에서 강제되는 락이 아님 → DB 엔진이 행/테이블을 막는 것이 아니라, 같은 ID로 애플리케이션이 요청할 때만 블록합니다.

즉, 다른 세션/트랜잭션이 같은 Advisory Lock을 요청하면 기다리게 됩니다.

하지만 DB의 일반적인 SELECT (읽기) 쿼리 자체를 막지는 않습니다.
→ SELECT 자체가 Advisory Lock ID를 요청하지 않는 한 자유롭게 실행됩니다.

**
Advisory Lock 을 활용하면 숙소+날짜 단위로 락 범위를 제한할 수 있어서
중복 예약 방지를 위한 최소한의 직렬화만 보장하면서 나머지 병렬로 처리될 수 있는 것들은 동시에 처리할 수 있도록 하기에 저의 문제상황에 가장 적합한 해결책이라고 느꼈습니다.**

DB 제약조건(UNIQUE + EXCLUDE) 활용 (PostgreSQL 전용 )

PostgreSQL은 동시성 제어를 위해 PostgreSQL의 EXCLUDE 제약 조건을 추가하여
이를 통해 데이터베이스 레벨에서 날짜가 겹치는 예약을 원천적으로 차단할 수 있습니다.

• 같은 accommodation_id + 겹치는 daterange를 가진 예약 삽입 시도 시
  • PostgreSQL이 자동으로 에러 발생 (exclusion constraint violation)
  • 따라서 SELECT FOR UPDATE 락이 불필요

이러면 동시에 두 트랜잭션이 겹치는 예약을 삽입하려 하면 DB가 직접 Conflict 에러(제약조건 위반) 을 던집니다. 실무에서도 자주 사용되는 가장 “정확하고 우아한” 방법이라고 볼 수 있습니다.

마이그레이션

import { MigrationInterface, QueryRunner } from "typeorm";

export class AddExcludeConstraintToReservation1761639317235 implements MigrationInterface {

    public async up(queryRunner: QueryRunner): Promise<void> {
        // EXCLUDE 제약 조건 추가
        // - 같은 accommodation_id에 대해
        // - check_in과 check_out 기간이 겹치는 경우
        // - status가 'CANCELLED'가 아닌 예약은 동시 존재 불가
        await queryRunner.query(`
            ALTER TABLE reservations
            ADD CONSTRAINT reservation_no_overlap_exclude
            EXCLUDE USING gist (
                accommodation_id WITH =,
                daterange(check_in, check_out, '[]') WITH &&
            )
            WHERE (status != 'CANCELLED')
        `);
    }

    public async down(queryRunner: QueryRunner): Promise<void> {
        // EXCLUDE 제약 조건 제거
        await queryRunner.query(`
            ALTER TABLE reservations
            DROP CONSTRAINT IF EXISTS reservation_no_overlap_exclude
        `);
    }

}

제약 조건 정의

  Exclusion,
} from 'typeorm';
import { User } from './user.entity';
import { Accommodation } from './accommodation.entity';
import { Review } from './review.entity';

export enum ReservationStatus {
  PENDING = 'PENDING',
  CONFIRMED = 'CONFIRMED',
  CANCELLED = 'CANCELLED',
}

@Entity('reservations')
@Exclusion(
  `USING gist (accommodation_id WITH =, daterange(check_in, check_out, '[]') WITH &&) WHERE (status != 'CANCELLED')`,
)
export class Reservation {
  @PrimaryGeneratedColumn()
  id: number;

  @Column({ type: 'int' })
  user_id: number;

  @Column({ type: 'int' })
  accommodation_id: number;

  @Column({ type: 'date' })

---