요구사항 분석 및 다이어그램 작성
요구사항 분석
주요 유저 대기열 토큰 기능•
대기열 토큰
◦
정보 : 현재 대기 순서, 예상 잔여 대기 시간, 활성 여부
토큰 관리 테이블 필요
◦
대기열 번호 발급 및 조회 시 토큰 관리 테이블에 등록된 토큰 중 가장 마지막 active와 id 차이로 계산
◦
결제 시 토큰 만료
◦
일정 시간 주기로 n명씩 토큰을 만료 & 입장 처리
◦
예약 가능 날짜 API, 좌석 API, 좌석 예약 요청 API, 결제 API 호출 시 사용
기본 예약 가능 날짜 / 좌석 API•
날짜 조회
◦
유저 토큰 필요, 대기열 토큰 필요
◦
콘서트 선택 기능은 필요할까?(여러 콘서트 중 어떤 콘서트의 예약 가능한 날짜 선택)
◦
없다면 하나의 콘서트만 대응하기 위해 서비스 개발하는건데, 비즈니스 모델 상 여러 콘서트를 두는건 너무 당연한거 아닐까
◦
날짜 조회 시 콘서트에 대한 정보(id)를 파라미터로 같이 받아야함
•
좌석 조회
◦
유저 토큰 필요, 대기열 토큰 필요
◦
현재 50개 → 더 늘어날수도(콘서트에 따라 다름 + 큰 콘서트라면 몇 만 석 존재할수도)
◦
좌석 조회 시 몇 만 석에 대한 조회 발생 → 섹션별로 나누는게 어떤지
◦
섹션 API → 좌석 API 호출 순으로
◦
콘서트 일정 id를 통해 섹션 API 호출 → 콘서트 일정에 잡힌 장소 검색 하면서 섹션도 Join으로 같이 가져오기
주요 좌석 예약 요청 API•
유저 토큰 필요, 대기열 토큰 필요
•
좌석을 섹션별로 분리했다면 API 요청 시 섹션 정보도 필요
•
추후 Redis로 변경될 것을 고려해서 기능 작성해야함(삭제하기 좋은 코드를 만들자)
◦
좌석과 좌석 예약을 분리하여 추후 Redis로 바뀔 부분을 좌석 예약 테이블로 처리
•
좌석 예약 시 5분간 임시 배정 기능
◦
expiredAt 필드를 두고 좌석 예약 시 예약 시점부터 5분
available 같은 boolean 타입 필드를 두는건…?
•
결제된 좌석은 어떻게 표현할 것인가
1.
expiredAt을 nullable한 필드로 만들고, 결제되면 null 넣어두기
2.
paid와 같은 별도의 boolean 컬럼을 두기
◦
예약 가능한 좌석 조회 시 join으로 expiredAt보다 이후이면서 paidAt이 null인 레코드 조회
기본 잔액 충전 / 조회 API•
잔액 충전
◦
유저 토큰 필요
◦
콘서트 예약 전 미리 충전해두는 경우도 존재 → 대기열 토큰 없이 수행
◦
금액을 직접적으로 충전하는만큼 동시성 제어 포인트가 되어야한다.
◦
유저 정보와 동일한 테이블에서 관리하는게 좋을까?
▪
잔액 관리는 유저와 동일 테이블에서, 충전 내역은 별도의 테이블에서 관리하자
•
잔액 조회
◦
유저 토큰 필요
◦
현재 잔액을 유저 테이블에 저장 → 단순히 조회하여 반환
주요 결제 API•
유저 토큰 필요, 대기열 토큰 필요
•
유저 잔액 관리
◦
잔액이 충분한 경우 결제 시도
▪
결제 진행 및 잔액 차감
◦
잔액이 부족한 경우 결제 시도
▪
잔액 부족하다고 예외 발생 후 실패 처리
•
좌석 소유권 배정
◦
좌석 테이블에서 해당 좌석 soldOut 지정
◦
예약 테이블에서 좌석 - 유저 정보 바탕으로 예약 정보 추가
•
결제는 무엇을 결제하는지 관심이 없다
◦
한 명이 여러 좌석 예매 → 1 : N 중간 테이블
◦
테이블 : ??(아이템) - 결제 아이템 - 결제
•
동작순서 : 포인트 검증 → 좌석 예약 검증 → 결제 → 포인트 차감
플로우 차트
시퀀스 다이어그램
유저 토큰 발급
대기열 토큰 발급
대기번호 조회
토큰 상태 변경 스케줄러
콘서트 정보 / 콘서트 일정 정보 / 콘서트 좌석 조회
좌석 예약
잔액 조회
잔액 충전
결제
