콘서트 예약 서비스

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

Description

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

Requirements

  • 아래 5가지 API 를 구현합니다.
    • 유저 토큰 발급 API
    • 예약 가능 날짜 / 좌석 API
    • 좌석 예약 요청 API
    • 잔액 충전 / 조회 API
    • 결제 API
  • 각 기능 및 제약사항에 대해 단위 테스트를 반드시 하나 이상 작성하도록 합니다.
  • 다수의 인스턴스로 어플리케이션이 동작하더라도 기능에 문제가 없도록 작성하도록 합니다.
  • 동시성 이슈를 고려하여 구현합니다.
  • 대기열 개념을 고려해 구현합니다.

API Specs

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

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

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

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

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

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

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

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

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

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

5️⃣ 주요 결제 API

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

💡 **KEY POINT**

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

 


 

1. 문제 (과제, 프로젝트를 진행하면서 부딪혔던 기술적인 문제)

 

이번 주차 과제는 문서작성 위주였다.
요구사항을 분석하고 마일스톤, 시퀀스 다이어그램, ERD, API Spec을 작성하고 MOCK API까지 만들면 됐다.
그래서 이번 주는 조금 여유롭겠구나~ 했다.

하지만 그거슨 경기도 오산이었...(문서 작업 뚝딱 해내시는 팀장님 리스펙트...)

앞선 주차에 비해 분석해야 할 요구사항이 늘어났고, 생각해야 하는 부분이 많았다.
예를 들면, 유저와 토큰의 관계는 어떻게 맺을 것인가, 대기열 검증은 어디까지 적용할 것인가 등등등.
또한 가장 큰 핵심 문제.
폴링으로 대기열을 확인한다
이게 대체 무슨 말인지 도통 이해가 가지 않았다.
그래서 이 분석에 시간이 가장 많이 걸려서 문서 작업 시작이 늦었다.
만약 팀원들끼리 나눠서 작성하지 않았다면 시간 내에 못 했을 거야...

 

2. 시도

폴링을 처음 들어봐서 구글링을 해보았다.
폴링이 일정주기를 갖고 서버와 응답을 주고받는 방식을 일컫는다는 것을 깨달았다.
대기열은 큐로 만들면 되는 것이 아닌가 막연하게 생각했다.
그렇다면 이 폴링으로 대기열을 확인하는 방법이 대체 뭐지?
이 부분은 팀원들과 얘기를 해보아도 도통 알 수가 없었다.

 

3. 해결

다행히 우리에겐 멘토링 시간이 있었다.🙌
한 시간의 멘토링 시간 거의 대부분을 대기열에 관한 설명을 들었다.
상세하게 설명해주신 이석범 코치님께 감사드림다.

 

4. 알게된 것

폴링을 백단에서 어떻게 구현하는 것인가라고 계속 고민했던 것이 무색하게 폴링은 그냥 클라이언트 쪽에서 요청하는 것이었다.

(생각해보니 당연한 게 서버 안에서 데이터를 계속 확인하는 거면 그냥 배치 돌리면 됐...)

즉, 처음 대기열을 위한 토큰을 발급 받은 후 페이지에 대기하면서 몇 초마다 요청을 보내도록 프론트 에서 구현하고, 에서는 요청이 들어왔을 때 토큰이 없다면 토큰을 발급하고 대기열에 넣어준 뒤 같은 요청이 들어왔을 때 토큰이 있다면 대기열의 순서를 확인하는 로직을 짜면 됐던 것이다. 그리고 순서 확인 시 토큰이 유효하다면 다음 페이지로 넘어갈 수 있도록 하고.(아마도)
또한 대기열 쪽은 일정 기간 마다 토큰의 만료 여부를 체크하는 스케쥴러를 만들면 오케이

 


 

Keep : 현재 만족하고 계속 유지할 부분

 

지난주에 DM과 아고라를 더 적극 활용해야겠다 생각했는데, 우선 팀원들과의 대화 및 멘토링으로 해결되는 부분이 있어 아고라까지는 활용을 하지 않았다.
이번주도 더 활발한 의견 교환을 할 예정

 

Problem : 개선이 필요하다고 생각하는 문제점

지식 부족과 정립되지 않은 생각들로 머릿속이 혼돈의 카오스인 점?
때문에 과제 진행이 더디다.

 

Try : 문제점을 해결하기 위해 시도해야 할 것

이거슨 더 공부를 하고 더 많이 물어보는 수 밖에...🥲

728x90

'항해99 플러스' 카테고리의 다른 글

6주차 회고록  (0) 2024.07.27
1년차 주니어 개발자의 항해 플러스 백엔드 5주차 회고록  (0) 2024.07.20
2주차 회고록  (0) 2024.06.29
1주차 회고록  (0) 2024.06.22
시작하는 마음  (2) 2024.06.15

+ Recent posts