드디어 본격적으로 자바, 객체지향, 토비의 스프링 공부가 마무리 되어가 애초 목표했던 안정적인 대용량 트래픽 처리가 가능한 인터파크 같은 온라인 대용량 티켓팅 서버를 구축해보려 한다.
점점 경력이 쌓여감에 따라, 이전까지 해왔던 경험과 지식만으로는 부족함을 느꼈고,
시니어 백엔드 개발자가 되기위해 어떤 것이 필요한가를 찾아봤을 때 가장 많이 나온 키워드는 안정적인 대용량 트래픽 처리였다.
이런게 가능할만한 서비스가 뭐가 있을까 생각해보니, 인터파크에서 접속하자마자 한국시리즈 예매를 실패했던 경험이 떠올라 인터파크 같은 온라인 대용량 티켓팅 서버를 구축해볼려고 결정했다!
구상한 내용은 아래와 같다.
요약
- 선택한 공연과 좌석에 대한 예약 및 결제 서비스를 제공합니다.
- 공연을 선택하면 해당 공연 전체 좌석에 대한 예약 완료 여부, 잔여 좌석 수를 표시합니다.
- 이때, 동시 접속자가 임계치를 넘어가면 대기 순번을 제공해 대기가 완료되는 순서대로 예약할 좌석 선택 및 결제를 진행할 수 있도록 합니다.
- 결제가 완료되면 선택한 공연과 좌석이 예약 완료되고, 유저는 해당 내역을 확인 및 취소할 수 있습니다.
목표
- 특정 시각 예약 동시 오픈 등 데이터의 변경이 급증하는 대용량 트래픽 상황에서 유저가 안정적으로 서비스를 사용할 수 있게 한다.
- 예약 완료&취소 발생 시 좌석 예약 상태를 빠르게 반영해 과거 상태가 표시되거나, 잘못 표시하여 불필요하게 유저가 결제 페이지로 이동하거나 예약에 실패하지 않도록 한다.
아키텍처 선택
- 어떤 방식의 아키텍처를 선택할지 고민하다가, 내가 티켓팅 서비스를 만들려하지만 티켓팅이라는 도메인에 대해 정확히 알거나, 내부 동작에 대해 생각해본 적이 없다는 것을 깨달았다!
- 재작년에 이직한 현 직장에서 개발하는 서버의 도메인 또한 디지털 향기 솔루션이라는 생소함을 가지고 있는데, 초기에 기술적 역량과는 별개로 도메인 자체가 이해가 안가 요구사항과 다소 동떨어진 개발 결과물이 나왔던 경험이 생각났다.
- "Garbage in, Garbage out"이라는 유명한 문장이 있는데 잘못된 값이 들어가면 잘못된 결과가 나온다. 즉, 요구사항을 정확히 이해하고 개발하는 것에 대한 중요성을 강조한 것 이라고 생각되는 문장이다.
- 따라서, 도메인에 대한 이해도를 올려, 정확한 요구사항을 바탕으로 복잡한 기술적 문제를 최대한 직관적으로 만들어 풀고싶었고, 이러한 도구로 DDD를 선택했다.
DDD 입문 도서로 유명한 도메인 주도 개발 시작하기를 읽으며 먼저, 구현 서비스에 대한 이벤트 스토밍을 진행해보았다.
이벤트 스토밍
- 회원, 공연, 결제, 대기로 경계를 분리했다.
- 커맨드에 따라 발생하는 이벤트들을 정리했고, 발생 흐름을 화살표로 연결했다.
- 기술적, 정책적으로 결정이 필요한 사항들은 핫스팟으로 표시해두었다.
이제 이벤트 스토밍을 통해 나온 결과를 실제 어떤 기술로 풀지 계획해야할 차례다.
설계 2편에 이어서 할 예정..
매일 발전