📌 예약하기 플로우

1.0. 예약하기 선택

1. 프론트에서 다음 정보를 담아서 예약가능 시간 반환 API 호출
   1. 식당 리스트 → 오늘부터 30개의 날짜별 예약가능여부 반환 API
      • 어느 식당 (식당 PK)
      • 언제 (연, 월, 일(당일)) → LocalDateTime
   2. 식당 상세 화면 & 예약하기 버튼 클릭 시 → 년, 월, 일을 받아 해당 날짜에 예약 가능여부 반환 API (✅ 완료)
      • 어느 식당 (식당 PK)
      • 언제 (연, 월, 일, 시간, 분) → LocalDateTime

2.0. 반환받은 예약가능 시간 리스트 중 하나 선택 → 예약선점 API (✅ 완료) 호출

1. 앞서 선택한 예약정보 기반 (식당, 날짜, 예약시간, 좌석)

2. 검증 (동시접속 문제 발생 가능 → 2차 때 해결)

   • 지금(누르는 시점)에 해당 자리가 예약 가능한 상태인가?
     • if 예약 가능좌석 수 == 0 인가?
     • 식당 + 날짜 + 예약시간(타임슬롯) 기반 예약정보가 Reservation 테이블에 존재하는가?
       • 상태가 CANCELED/FAILED 이외인 경우
       • 해당 방법은 검증 과정이 너무 복잡함 → 좌석수 판단 방법이 좋아보임

   2.1. “예약 불가능하다”

   • 모달 출력
     • “이미 다른 사용자가 결재중입니다.”
     • “예약 완료된 좌석입니다.”

   2.2. “예약 가능하다” → 선점

   1. [Reservation] 테이블에 IN_PROGRESS 상태의 예약정보 하나 생성
   2. [Seat_Availability] 테이블에 예약가능 좌석 수 - 1

   3.0. 결제 창으로 버튼 클릭 후

   3.1. “결제 실패 + 뒤로 가기 + 타임아웃”

   예약선점취소 API 호출

   1. 예약정보 상태 변경

      IN_PROGRESS → CANCELED/FAILED

   2. 예약가능 좌석 수 + 1

   3.2. “결제 성공”

   예약완료 API 호출

   1. 예약정보 선점상태 검증

   2. 예약정보 상태 변경

      IN_PROGRESS → COMPLETE

📌 예약 취소 플로우

예약 취소하기 버튼 클릭 시, 예약취소 API 호출

1. [Reservation] 테이블의 예약정보 상태 변경

   COMPLETE → CANCELED

2. 예약 취소의 합리성 검증 (티켓 반환여부 결정) → 연, 월, 일까지 비교 00시 기준

   LocalDateTime → LocalDate → 내부 메서드로 비교

   예약일 - 검증시점 < 1 Day

   • 티켓 반환 ❌

   예약일 - 검증시점 ≥ 1 Day

   • 티켓 반환 ⭕
   • 사용자 normal_ticket_count + 1

3. 빈자리 알림 전송

   방법 1. 예약취소 API 내, 빈자리 알림전송 기능 포함

   기능 분리가 안되고, 취소 이벤트에 오랜 시간이 걸릴 것으로 예상

   ⭐ 방법 2. 예약취소 API 와 빈자리 알림전송 API 분리

   기능 분리가 가능, 취소와 알림 전송을 구분

📌 선점 기능 플로우

캘린더에서 날짜/ 좌석 선택 시, 선점 API 호출

1. “ 100개의 좌석이 예약가능 상태로 열렸는데, 1000명이 몰려와서 예약시도”
   • 발생 가능 이슈
     • 동시성 문제 발생가능

       • 초과 예약 문제

         동시에 여러 요청이 처리되면서 좌석 수가 0 이하로 내려가거나 이미 없는 좌석이 예약되는 경우.

       • 데드락(Deadlock)

         여러 사용자가 동시에 동일한 좌석 데이터를 수정하려고 하면 교착 상태가 발생할 수 있음.

       • 응답 시간 지연

         과도한 트래픽으로 인해 데이터베이스나 애플리케이션의 응답 시간이 늘어나는 경우.