[내일배움캠프 TIL, Day 45] 파이널프로젝트 : 캐치테이블 서비스 분석
1. 오늘 학습 키워드
- 도메인 경계 설정: 기능 유사성과 트래픽 패턴 기준으로 도메인을 어떻게 나눌 것인가
- 티케팅 재정의: 별도 도메인이 아닌 “오픈 일시가 있는 예약”으로 통합
- 결제 모듈 위치: MSA에서 결제를 독립 서비스로 분리할 것인지, 예약 서비스 내 패키지로 둘 것인지
- PG 연동 제외 결정: Redis 분산 락 + 노쇼 패널티로 선착순 신뢰성 확보
2. 설계 논의 내용 정리
파이널 프로젝트 첫 날, 팀이 새로 바뀌고 각자 관심 도메인으로 제출한 주제를 바탕으로 토의했었다.
공통적으로 이커머스와 티케팅서비스가 많았고, 두 가지 분야에서 어떤 서비스를 구현할 수 있을지 기존 서비스들을 레퍼런스로 숙박예약, 한정판매 시스템 등 여러가지 주제를 논의하다가
그 두가지 성격을 두드러지는 서비스인 캐치테이블 서비스를 모방한 프로젝트를 진행해보기로 결정했다.
💡 고민 1 — 우리 서비스에서 ‘티케팅’의 의미는 무엇인가
SA 작성 과정에서 ‘티케팅’의 정의를 두고 두 가지 해석이 충돌했다.
후보 A — 일반 예약 vs 오픈 예약
일반 예약은 원하는 날짜·시간 슬롯을 즉시 선택하는 방식이다. 오픈 예약은 특정 일시에 예약이 열리고, 그 순간 선착순으로 신청하는 방식이다.
두 방식의 실질적인 차이를 분석해보면 “슬롯 오픈 일시 유무”와 “트래픽이 한 시점에 몰리는가”뿐이다.
데이터 구조도 거의 동일하기 때문에 별도 도메인으로 나눌 이유가 없다는 결론이 나왔다.
후보 B — 일반 예약 vs 이벤트 상품권 구매
캐치테이블의 실제 서비스에는 레스토랑이 이벤트 할인 상품권을 판매하는 기능이 있다. 이 방향으로 가면 예약이 아닌 구매(결제) 도메인이 추가되고, 구현범위가 더 넓어질 것 같다는 의견이 있었다.
최종 결정
이벤트 상품권 구매 방식은 캐치테이블 본래 서비스 범위에서 벗어난다고 판단해 제외했다.
구현 관점에서도 사전오픈으로 통해 예약이 몰리는 상황(티케팅)이나 인기가 있는 음식점에서의 일반예약이 다르지 않은 것 같다는 결론으로 의견이 모아졌다.
“트래픽이 한 시점에 몰리는 선착순 신청”이라는 챌린지(Redis 분산 락, DECR 재고 차감)는 그대로 유지되므로, 티케팅의 의미보다는 예약과 웨이팅기능에 중점을 두기로 하였다.
💡 고민 2 — 결제 모듈은 마이크로서비스로 분리해야 하는가
PG 연동을 제외하기로 결정한 이후에도 한 가지 고민이 남았다.
결제 로직(금액 계산, 환불 규칙, 결제 상태 관리 등)을 독립 마이크로서비스로 설계해둘 것인지, 아니면 Reservation Service 내 도메인 패키지로 둘 것인지다.
독립 마이크로서비스로 분리하는 경우
실제 서비스라면 결제는 독립 서비스로 분리하는 것이 정석이다. 결제는 예약과 생명주기가 다르고, PG사 연동·환불 정책·정산 처리 등 고유한 책임 영역이 있기 때문이다. 확장성 면에서도 분리된 구조가 유리하다.
Reservation Service 내 패키지로 두는 경우
PG 연동이 없는 현재 프로젝트에서 결제 서비스는 실질적으로 “예약 확정 시 금액을 기록하는 로직” 수준이다.
예약 확정과 결제 처리가 다른 서비스에 있으므로 기간, 중요도 대비 오버엔지니어링일 수 있다.
결정
실제 서비스에서는 분리가 맞지만, 의견이 분분하니 처음 설계(기간, 구현 비중)에 기반해서 reservation 내에 두는 것으로 우선 두고 피드백을 받아보기로 했다.
3. todo
- ERD 초안 작성
- API 명세 초안 작성
- 예약 상태 플로우 시퀀스 다이어그램 작성
- 아키텍처 설계
#내일배움캠프 #단기Java #TIL #MSA #DomainDesign #Ticketing
Leave a comment