[KBOTicket] 티켓팅 시스템의 목표와 중점 설계 요소

주제 선정 이유

첫째, 야구 예매 시스템을 주제로 선정한 이유는 개인적인 야구에 대한 관심에서 비롯되었습니다.

올해 야구의 인기가 크게 상승하면서, 나 또한 경기 관람을 위해 예매를 자주 하게 되었습니다. 하지만 각 구단마다 예매 사이트가 분리되어 있어 불편함을 겪었고, 모든 구단의 티켓을 한 곳에서 예매할 수 있다면 얼마나 편리할까 라는 생각과 함께 티켓팅 로직이 궁금하여 해당 프로젝트를 시작하게 되었습니다.

 

둘째, 티켓팅 오픈일에는 대규모 사용자가 동시에 몰리면서 서버가 원활하게 작동하는 원리에 대해 궁금증이 생겼고, 이를 해결하는 방법을 배우고 적용하고 싶었습니다. 대규모 트래픽을 처리할 수 있는 서버 안정성을 확보하는 과정에서 많은 기술적 도전이 있을 것이라고 생각했습니다.

 

마지막으로, 티켓팅 시스템 특유의 선점 방식을 경험해 보고 싶었습니다. 기존 이커머스 시스템과는 다른 예매 로직을 가지고 있어, 이를 직접 구현하며, 차이를 이해하고 동시성 문제를 해결하고자 하였습니다.

 

이러한 이유로 야구 예매 시스템을 주제로 삼아 프로젝트를 진행하게 되었습니다.

 

 

프로젝트 목표

• 객체 지향 설계 원칙에 따라 개발하기
• 지속적인 성능 개선과 코드 리팩토링
• 티켓팅 과정에서의 동시성 이슈 해결
• 대용량 트래픽에도 대응 가능한 시스템 구축
• 가독성과 유지보수성을 높이는 클린 코드 작성

 

 

어디 중점을 두었는지

1. 좌석 선점 시 발생할 수 있는 동시성 문제 해결
   다수의 사용자가 동일 좌석을 동시에 선점하려고 하는 경우, 동시성 문제로 예매 실패, 중복 예약 등이 발생.
   → Redis와 Redisson을 활용하여 분산 락(Distributed Lock) 구현
   
   
2. 대규모 사용자 접속 시 서버 안정성 확보 방안
   티켓팅 당일 이벤트 시에는 수만 명의 사용자가 동시에 접속하여 높은 트래픽이 발생.
   → Kafka 활용

 

 

 

예매 백엔드 플로우

1. 회원가입/ 로그아웃

• 유저는 회원가입 및 로그인을 한다. (인증/인가)

2. 경기 목록 조회

• 원하는 경기 목록을 조회할 수 있으며, 이전 목록은 조회할 수 없다.
• 오픈된 경기에 한해서 경기 상세(예매) 페이지로 진입 가능
• 오픈 전인 경우 진입 불가능
• 비회원 진입 가능

3. 경기 상세(에매) 페이지 진입

• 인증된 유저만 이용 가능
• 경기 7일 전 오전 11시에 오픈 (스케줄러)
• 오픈과 동시에 사용자 접근 (대량의 트래픽이 몰리는 상황 가정)
• 대기열 구현

4. 좌석 선점 (선점 시간 : 7분)

• 인증된 유저만 이용 가능
• 다른 유저가 이미 선점한 좌석인 경우: 선점 불가
• 선점한 유저가 없는 경우 : 선점

5. 결제 (토스페이먼츠 이용)

• 선점 시간 이내에 결제 진행되어야 한다.
• 선점 시간 이내에 하지 못한 경우 선점된 좌석은 취소된다.

6. 결제취소 (토스페이먼츠 이용)

• 선점 시간 이내에 결제 진행되어야 한다.
• 선점 시간 이내에 하지 못한 경우 선점된 좌석은 취소된다.

7. 예매 상세 내역

• 인증된 유저만 이용 가능

 

 

DB 구조

 

 

 

 

 

서버 구성

추후에 이미지 첨부