02_요구사항분석 - loveAlakazam/hh-08-concert GitHub Wiki

요구사항 세부 정의 내용 정의

기능별 요구사항 세부내용 정의

어떤식으로 대기열 시스템을 구성해야될까?

은행창구 방식

요약: 한명이 끝나면 다음 한명이 들어오는 방식

은행에 가면 창구는 여러개 있고, 창구를 이용하려면 대기 번호표를 뽑아야한다. 가장 먼저 비는 창구에서 대기번호를 부르게되면, 이용자는 호출하는 창구로 가서 이용한다. 1개의 창구는 이용자 1명의 요청을 처리할 수 있다.

  1. 이용자는 은행창구 대기 번호표를 뽑았고. 대기번호는 101번이다.
  2. (모든 창구가 처리중 이면) 창구에서 대기 번호표 순서가 될 때까지 대기한다.
  3. 가장 먼저 비는 1번창구에서 이용자의 대기번호 101번을 호출하여 이용자는 1번창구로 간다.
  4. 다른 창구에서도 비어있어서 다음번호 102번을 호출한다.
  • 처리방식
    • 이용자의 순서는 대기번호표로 알지만 비어있는 창구가 이용자의 요청을 처리하기때문에 어디 창구에서 처리할지는 모른다.
    • 빠른 처리에 초점되어있어서 공정성보다는 효율성이 좋다.

놀이동산 방식

요약: 일정 주기마다 N명씩 나가고 M(놀이기구 이용정원)명씩 들어오는 방식 (N <= M)

놀이기구를 타러 줄을 서게되면, 내 순서가 올 때까지 정해진 줄에서 끝까지 기다려야한다. 아무리 앞에 자리가 나도, 내 순서가 될 때까지는 절대못탄다.

  1. 100명이 줄을 서고 있고 이용자는 51번째 순서이다.
  2. 앞 사람이 한명씩 타면, 순서가 점점 가까워지며 이용자 차례가 될때 입장할 수 있다.
  • 처리방식
    • 고정된 순서가 있으며 한명씩 순차적으로 입장할 수 있으며 내 순서 외에는 입장할 수 없다.
    • 내 순서가 올때까지 기다려야되며, 공정성에 중심이며 예측이 가능하다.
    • 앞사람이 한명씩 타면, 내 순서가 점점 가까워지기 때문에 앞에 몇명이 있는지 정확히 예측이 가능하다.

유저 대기열 토큰 기능

  • 서비스를 이용할 토큰을 발급받는다.
  • 토큰은 유저의 UUID 와 해당 유저의 대기열을 관리할 수 있는 정보 (대기순서 or 잔여시간 등) 을 포함
  • 이후 모든 API 는 대기열 토큰을 이용하여 대기열 검증을 통과해야 이용 가능
  • 기본적 폴링으로 본인의 대기열을 확인한다고 가정
  • 유저간 대기열을 요청 순서대로 정확하게 제공
  • 토큰은 UUID, userId, concertId, 상태, 생성시점, 만료시간(30분) 을 포함한다.
  • 토큰 상태는 WATING, ACTIVE 로 정의 한다.
  • 상태와 상관없이 토큰의 유효시간은 30분 이다.
토큰상태 상태 전환 조건 기능 API에 접근가능 여부 유효시간 상태 소멸 조건
WAITING 대기열 진입시 자동발급 기능 사용 불가 30분 ACTIVE 토큰 개수가 특정개수 미만일 경우 대기 순으로 WAITING이 ACTIVE로 전환할 경우 타임아웃
ACTIVE 대기열 통과 기능 사용 가능 30분 타임아웃

  • Polling 방식 (일정시간의 간격을 두고 반복호출하는 방식)으로 대기순번을 조회한다.

    • 폴링(Polling)은 요청자가 일정 간격으로 지속적으로 요청하는 방식이다. 콘서트의 대기열에서 따지자면, '이제 내차례야?'를 일정시간동안 계속 물어보는거와 같다.

  • 대기열 토큰들의 순서를 담당하는 대기열 큐도 토큰래포지토리에 포함되어있다고 가정하고 시퀀스다이어그램에 나타냈다.

  • 대기열 토큰 스케줄러는 5초 간격으로 대기열 큐에 있는 대기열 토큰들을 관리한다.

    • 스케줄러는 토큰의 유효시간이 만료된 토큰들은 삭제한다.
    • 스케줄러는 대기열을 통과하게되면 토큰의 상태가 대기(WAITING) 에서 활성화(ACTIVE)로 변경한다.

  • 활성토큰의 최대개수는 100 개이다.

예약 가능 날짜 / 좌석 조회 기능

  • 예약 가능한 날짜와 해당 날짜의 좌석을 조회
  • 예약 가능한 날짜 목록을 조회
  • 날짜 정보를 입력받아 예약 가능한 좌석정보 조회
  • 좌석정보는 1~50 까지의 좌석번호로 관리

  • 유효한 ACTIVE 토큰이 있어야 한다.

    • 시퀀스다이어그램 그리기 전략 : 현 API 를 기준으로 봤을때 토큰의 유효성검사는 비기능적인 요소이므로 점선으로 나타냈다. API와 직접적으로 관련있는 요소간의 연결은 실선으로 나타냈다.
    • 비즈니스로직에 필요하지만 직접적으로 연결되지 않은 부분은 점선으로 표기.
    • 비즈니스로직에 직접적으로 연결될 경우 실선으로 표기

  • 특정 콘서트의 예약 가능한 날짜를 먼저 조회후 날짜를 선택하고, 해당 날짜의 예약 가능한 좌석을 조회할 수 있다.

좌석 예약 요청 기능

  • 날짜와 좌석정보를 입력받아 좌석을 예약처리
  • 좌석 예약과 동시에 해당 좌석은 그 유저에게 5분간 임시 배정
  • 만약 배정 시간 내에 결제가 완료되지 않는다면 좌석에 대한 임시배정은 해제
  • 누군가에게 점유된 동안에는 해당 좌석은 다른 사용자가 예약 불가능

  • 유효한 ACTIVE 토큰이 있어야 한다.

  • 좌석상태와 예약상태 가 존재한다.

    • 좌석 상태
      • 예약 가능 상태
        • 한번도 예약되지 않았거나, 예약이 취소된 경우는 예약 가능 상태를 나타낸다.
      • 예약 불가능 상태
        • 5분간 임시예약상태
        • 예약확정 상태
    • 예약 상태
      • PENDING_PAYMENT: 임시 배정된 좌석에 대해 결제 대기중
      • CONFIRMED: 결제가 완료되어 에약이 확정된 상태
      • CANCELED: 임시예약 후 5분이 초과되었거나 사용자 요청으로 예약이 취소된 상태

  • 10초 간격으로 스케줄러가 실행하여, 현재 시각 기준으로 임시에약 시간 5분이 지나서 만료된 좌석의 상태를 "예약 불가능" 에서 "예약 가능" 으로 변경해야한다.

  • 임시 예약상태란 좌석상태: "예약 불가능" / 예약상태: "결제대기중(PENDING_PAYMENT)" 이다.

  • 스케줄러로 인해서 해당 만료된 좌석은 좌석상태: "예약 가능" / 예약상태: "취소(CANCELED)" 로 변경이 된다.

잔액 충전 / 조회 기능

  • 결제에 사용될 금액 충전
  • 사용자 식별자 및 충전 금액을 받아서 잔액을 충전
  • 사용자 식별자를 통해 해당 사용자의 잔액을 조회
  • 유효한 ACTIVE 토큰이 있어야 한다.
  • 초기 잔액은 0원이다.
  • 잔액 충전금액은 0보다 큰 양수여야한다.
  • 잔액 충전금액의 최소값은 1000 원이다.
  • 잔액 충전금액의 최대값은 100000 원이다.

결제 기능

  • 결제 처리하고 결제 내역을 생성
  • 결제가 완료되면 해당 좌석의 소유권을 유저에게 배정하고 대기열 토큰을 만료
  • 유효한 ACTIVE 토큰이 있어야 한다.
  • 임시예약 시간(5분)내에 결제가 이뤄져야 임시예약 에서 예약확정 으로 상태가 변경된다.
  • 예약확정된 좌석은 좌석상태: "예약 불가능", 예약상태: "예약확정(CONFIRMED)" 로 나타낸다.
  • 스케줄러는 확정된 좌석의 상태변경에 관여하지 않는다.