항해 플러스 서버 구축

🎤 콘서트 예약 시스템 🎤

✅ 과제 설명

💡 아래 명세를 잘 읽어보고, 서버를 구현합니다.

• **콘서트 예약 서비스**를 구현해 봅니다.
• 대기열 시스템을 구축하고, 예약 서비스는 작업가능한 유저만 수행할 수 있도록 해야합니다.
• 사용자는 좌석예약 시에 미리 충전한 잔액을 이용합니다.
• 좌석 예약 요청시에, 결제가 이루어지지 않더라도 일정 시간동안 다른 유저가 해당 좌석에 접근할 수 없도록 합니다.

🤔 요구사항

• 아래 5가지 API 를 구현합니다.

  • 유저 토큰 발급 API
  • 예약 가능 날짜 / 좌석 API
  • 좌석 예약 요청 API
  • 잔액 충전 / 조회 API
  • 결제 API

• 각 기능 및 제약사항에 대해 단위 테스트를 반드시 하나 이상 작성하도록 합니다.

• 다수의 인스턴스로 어플리케이션이 동작하더라도 기능에 문제가 없도록 작성하도록 합니다.

• 동시성 이슈를 고려하여 구현합니다.

• 대기열 개념을 고려해 구현합니다.

✏️ API Specs

1️⃣ 주요 유저 대기열 토큰 기능

• 서비스를 이용할 토큰을 발급받는 API를 작성합니다.
• 토큰은 유저의 UUID 와 해당 유저의 대기열을 관리할 수 있는 정보 ( 대기 순서 or 잔여 시간 등 ) 를 포함합니다.
• 이후 모든 API 는 위 토큰을 이용해 대기열 검증을 통과해야 이용 가능합니다.

기본적으로 폴링으로 본인의 대기열을 확인한다고 가정하며, 다른 방안 또한 고려해보고 구현해 볼 수 있습니다.

2️⃣ 기본 예약 가능 날짜 / 좌석 API

• 예약가능한 날짜와 해당 날짜의 좌석을 조회하는 API 를 각각 작성합니다.
• 예약 가능한 날짜 목록을 조회할 수 있습니다.
• 날짜 정보를 입력받아 예약가능한 좌석정보를 조회할 수 있습니다.

좌석 정보는 1 ~ 50 까지의 좌석번호로 관리됩니다.

3️⃣ 주요 좌석 예약 요청 API

• 좌석 예약과 동시에 해당 좌석은 그 유저에게 약 5분간 임시 배정됩니다. ( 시간은 정책에 따라 자율적으로 정의합니다. )
• 날짜와 좌석 정보를 입력받아 좌석을 예약 처리하는 API 를 작성합니다.
• 만약 배정 시간 내에 결제가 완료되지 않는다면 좌석에 대한 임시 배정은 해제되어야 하며 임시배정 상태의 좌석에 대해 다른 사용자는 예약할 수 없어야 한다.

4️⃣ 기본 잔액 충전 / 조회 API

• 결제에 사용될 금액을 API 를 통해 충전하는 API 를 작성합니다.
• 사용자 식별자 및 충전할 금액을 받아 잔액을 충전합니다.
• 사용자 식별자를 통해 해당 사용자의 잔액을 조회합니다.

5️⃣ 주요 결제 API

• 결제 처리하고 결제 내역을 생성하는 API 를 작성합니다.
• 결제가 완료되면 해당 좌석의 소유권을 유저에게 배정하고 대기열 토큰을 만료시킵니다.

💡 KEY POINT

• 유저간 대기열을 요청 순서대로 정확하게 제공할 방법을 고민해 봅니다.
• 동시에 여러 사용자가 예약 요청을 했을 때, 좌석이 중복으로 배정 가능하지 않도록 합니다.

👥 시나리오 요구사항 분석

[ API 별 시나리오 ]

1.유저 대기열 토큰 기능 시나리오

❓ 어떤식으로 대기열을 구성할 것인가 ❓

• 은행창구 방식
  • 1명이 끝나면 다음 1명이 들어오는 방식
    • 장점 : 개발자가 설정한 사용자 수만 예약이 가능, 서버 부하를 일정 수준 이하로 유지 가능
    • 단점 : 대기열에 있는 사용자는 무한정 기다릴 수 있음. 때문에 일정 시간을 주기로 사용자의 토큰을 활성화해주는 작업이 필요
• 놀이동산 방식
  • 일정 주기마다 N 명씩 나가고 M 명씩 들어간다.
    • 장점 : 은행창구 방식과는 달리 대기시간이 있다. ( Redis 의 TTL )
    • 만약 나가는 사용자보다 들어가는 사용자가 더 많다면? -> 서버 부하 발생

2.예약 가능 날짜 시나리오

• 유저는 앞으로 예약 가능한 날짜를 리스트로 전체 조회
  • 이미 예약이 찬 죄석은 조회 데이터에서 제외

3.좌석 시나리오

• 유저가 원하는 날짜의 예약 가능한 좌석들을 조회
  • 원하는 날짜보다 이전 날짜의 좌석들을 보여줄 것인지?
    • 원하는 날짜 시점부터 이후 날짜까지 남은 예약 가능한 좌석들을 조회
• 만약 원하는 날짜에 예약 가능한 죄석이 없다면 “없다는 메시지” response

4.좌석 예약 요청 시나리오

• 유저는 원하는 날짜의 하나의 좌석만 예약이 가능
  • 만약 중복 예약할 시 오류 메시지 response 5.잔액 충전 / 조회 시나리오
• 유저가 잔액을 충전 (max 를 둬야할지는 일단 고민)
• 유저가 잔액을 조회
  • 유저에게 발급된 토큰으로 해당 유저임을 인증하고 -> 인증 확인 시 조회가 가능
  • 인증된 유저가 아닐 시 조회 접근 불가

6.결제 시나리오

• 잔액이 있다면 )
  • 유저가 잔액을 조회 가능
• 잔액이 없다면 )
  • 유저에게 “잔액이 없음” 메시지 response

📝 시퀀스 다이어그램

part1: 대기열 생성 및 관리

🧭 Milestone

마일스톤

1주차 (10월 05일 - 10월 11일)

• 프로젝트 시작 및 초기 설정
  • 프로젝트 시나리오 선정 및 시나리오 요구사항 분석
  • 기술 스택 선정
  • MileStone 작성 및 시퀀스 다이어그램 작성
  • ERD 설계
  • API 명세 작성
  • Mock API를 작성합니다.

< 주요 내용 >

STEP 1

• 시나리오 선정 및 프로젝트 Milestone 제출

• 시나리오 요구사항 별 분석 자료 제출

  시퀀스 다이어그램, 플로우 차트 등

• 자료들을 리드미에 작성 후 PR 링크 제출

STEP 2

• ERD 설계 자료 제출
• API 명세 및 Mock API 작성
• 자료들을 리드미에 작성 후 PR링크 제출 ( 채택할 기본 패키지 구조, 기술 스택 등 )

2주차 (10월 12일 - 10월 18일)

• 대기열 기능 개발 시작
  • 토큰 발급 API 작성
  • 대기열 기능 구현
• 예약 가능한 날짜/좌석 조회 API 구현

3주차 (10월 19일 - 10월 25일)

• 예약 가능한 날짜/좌석 조회 API 구현 ( 2 주차에 못끝냈을 경우)
• 좌석 예약 요청 API 구현
• 잔액 충전/조회 API 구현
• 결제 API 구현
• 리펙토링

step6 에서 한 번더 고민해본 대기열 시나리오(대기열에 아무도 없다면?)

유저는 회원가입 시 서버에게 UUID 를 반환받는다.

유저는 UUID 를 가지고 대기열에 진입한다. (바로 대기열 진입이 킥)

1. 대기열 진입 과정의 시나리오 ( 대기열에 누군가 있을 경우? )

• 유저가 대기열에 진입하지 않은 경우:
  1. 유저가 좌석 조회를 시도.
  2. 서버가 대기열에 진입하지 않았음을 확인하고, 대기열 토큰 발급을 안내.
  3. 유저가 대기열에 진입하여 대기열 토큰을 발급받은 후 좌석 조회 API를 호출.
• 유저가 대기열에 진입한 후:
  1. 유저는 대기 상태에서 폴링 API를 통해 자신의 대기 상태를 확인.
  2. 대기 순번이 도착하면 좌석 조회 및 예약을 진행할 수 있습니다.

2. 대기열 진입 과정의 시나리오 ( 대기열에 아무도 없을 경우? )

• 대기열 진입
  • 유저는 대기열에 진입하는 요청을 보낸다
  • 대기열에 아무도 없다면 → 서버는 유저에게 대기 1번을 할당하고 즉시 처리 가능한 상태로 만들어준다.
• 바로 죄석 조회 및 콘서트 예약 가능
  • 대기가 1번이었던 유저는 대기할 필요가 없다. 따라서 바로 좌석 조회 및 콘서트 예약이 가능해야 한다.
  • 이 과정은 유저가 바로 대기열에서 빠져나오는 것처럼 처리되어야 하고, 바로 토큰을 이용해 다른 기능들을 정상적으로 이용 가능해야한다.

🛠️ 기술 스택

Architecture

- Testable Business logics
- Layered Architecture Based
- Clean Architecture

DB ORM

- Spring JPA
- MYSQL

Test

- JUnit 

📝 API 명세

🤔 ERD