티켓 예매 시스템 설계

티켓 예매 시스템 아키텍처: API부터 확장성까지

티켓 예매 시스템은 이벤트 탐색, 파라미터 기반 검색, 이중 판매 없는 안정적인 예약을 지원해야 합니다. 읽기 작업을 위한 데이터 가용성과 쓰기 작업을 위한 엄격한 일관성에 중점을 둡니다. 예상 부하—인기 이벤트 기준 최대 1천만 명의 사용자, 500ms 미만의 검색 지연 시간, 100:1의 읽기-쓰기 비율.

주요 엔티티: 이벤트(날짜, 설명, 유형 포함), 사용자, 공연자, 장소(좌석 배치도 포함), 티켓(좌석, 가격, 상태 포함), 예약(티켓 목록과 상태 포함).

API 엔드포인트 설계

API는 세 가지 우선순위 기능을 중심으로 구축됩니다. 단순한 엔드포인트부터 시작하여 설계가 진행됨에 따라 정제합니다.

이벤트 보기:

GET /events/:id -> Event & Venue & Performer & Ticket[]

이벤트 상세 정보, 장소, 공연자, 그리고 클라이언트에서 좌석 배치도를 렌더링하기 위한 티켓 목록을 반환합니다.

검색:

GET /events/search?keyword={keyword}&start={start_date}&end={end_date}&pageSize={page_size}&page={page_number} -> Event[]

키워드, 날짜, 페이지네이션으로 필터링하여 높은 처리량을 달성합니다.

예약 (초기 버전):

POST /bookings/:eventId -> bookingId
{
  "ticketIds": string[],
  "paymentDetails": ...
}

나중에 트랜잭션 신뢰성을 위해 예약과 확정으로 분리됩니다.

하이 레벨 아키텍처

시스템 구성 요소

• API 게이트웨이: 라우팅, 인증, 속도 제한, 로깅.
• 이벤트 서비스: DB에서 이벤트, 장소, 공연자 데이터 읽기.
• 검색 서비스: 필터링이 포함된 검색 쿼리 처리.
• 예약 서비스: 트랜잭션으로 예약 관리.
• 데이터베이스: ACID 트랜잭션을 위한 PostgreSQL (예약, 티켓), 읽기 작업을 위한 NoSQL 또는 캐시 (이벤트, 장소).

보기 흐름: 클라이언트 → 게이트웨이 → 이벤트 서비스 → DB → 좌석 배치도가 포함된 응답.

부하 하에서의 확장

이벤트당 1천만 DAU를 위해 사용:

• 캐싱: 자주 읽는 데이터(이벤트, 검색)를 위한 Redis.
• 샤딩: Tickets/Bookings에서 eventId 기준.
• CQRS: 읽기(읽기 복제본)와 쓰기(마스터) 분리.
• 로드 밸런서: 서비스 간 트래픽 분산.

100:1 읽기/쓰기 비율은 읽기 복제본과 정적 데이터(좌석 배치도)를 위한 CDN에 우선순위를 둡니다.

예약 상세 및 일관성

중요 영역—이중 예약 방지. PostgreSQL 트랜잭션과 Serializable 격리 수준 또는 티켓 버전에 대한 낙관적 동시성 제어(OCC).

프로세스:

• 클라이언트가 ticketIds 선택.
• 예약 서비스가 트랜잭션 시작: Tickets에 SELECT FOR UPDATE.
• 상태 확인(사용 가능), 예약됨으로 업데이트.
• 예약 레코드 생성.
• 결제 확인 → 상태 확정됨.

Tickets 테이블 예시:

| id | event_id | section | row | seat | price | status | version |

|----|----------|---------|-----|------|-------|--------|---------|

| 1 | 123 | A | 1 | 5 | 100 | available | 1 |

OCC: UPDATE 시 버전 확인, 충돌 시 거부.

높은 동시성을 위해—Redis에 임시 홀드(TTL 10분).

검색 최적화

기본 SQL 필터링은 1천만 규모로 확장되지 않습니다. 다음으로 전환:

• 키워드, 공연자, 장소별 전체 텍스트 검색을 위한 Elasticsearch.
• 필드 포함 이벤트 인덱싱: 이름, 날짜 범위, 위치.
• 필터(날짜, 유형)를 위한 패싯 검색.

흐름: 검색 서비스 → ES 쿼리 → 집계 → Redis에 캐싱.

인기 이벤트 사전 로딩으로 <500ms 지연 시간 달성.

확장성 심층 분석

데이터베이스

• 마스터 PostgreSQL (예약, 티켓)—eventId 기준 샤딩.
• 읽기 복제본—이벤트 보기를 위해 10개 이상.
• Redis—세션, 임시 홀드, 인기 이벤트.
• Elasticsearch—검색, 분석.

데이터 마이그레이션: 이벤트 서비스가 Kafka에 쓰기 → CDC → 복제본/ES.

모니터링 및 장애 허용

• 서비스 내 서킷 브레이커.
• 헬스 체크, 자동 확장.
• 백업: S3에 WAL 아카이빙.

핵심 요약

• 엄격한 일관성은 예약 트랜잭션에서만, 검색은 최종적 일관성.
• OCC + Redis 임시 잠금으로 차단 없이 99% 충돌 방지.
• CQRS/ES로 100:1 부하 하에서 <500ms 검색 보장.
• eventId 기준 샤딩으로 1천만 이상 DAU 확장.
• API 게이트웨이가 보안과 스로틀링을 중앙화.

— Editorial Team