드디어 본격적으로 자바, 객체지향, 토비의 스프링 공부가 마무리 되어가 애초 목표했던 안정적인 대용량 트래픽 처리가 가능한 인터파크 같은 온라인 대용량 티켓팅 서버를 구축해보려 한다.점점 경력이 쌓여감에 따라, 이전까지 해왔던 경험과 지식만으로는 부족함을 느꼈고, 시니
지난번 이벤트 스토밍 설계에 이어 이번엔 이 설계를 어떻게 기술적으로 구현할지에 대한 고민을 해보려 한다. 서비스는 회원, 공연, 대기, 결제 도메인으로 나뉘는데 가장 중요하고 트래픽이 많이 발생할 것으로 보이는 공연/대기/결제 도메인 먼저 설계하려한다. 이 중
이전 설계 2편에 이어 해당 편은 도입 검토중인 CQRS에 대해서 알아본 것을 정리하고 어떤 형태로 적용할지 결정하려 한다.명령(시스템 데이터 변경) 역할을 수행하는 구성 요소와 쿼리(시스템 데이터 조회) 역할을 수행하는 구성 요소를 나누는 것.명령시스템 데이터 변경기
지난 3편에서의 CQRS 개념까지 반영해, 길고길었던 설계를 마무리하고 다음과 같은 산출물이 나왔다.Redis의 SortedSet을 사용해 유저들을 대기 순번 기준으로 정렬해 큐처럼 사용현재 순위(순번) 조회가 많이 발생할 것으로 예상되어, 해당 작업에 O(N)이 발생
티켓팅 서비스 개발 중 관습처럼 사용하던 엔티티 ID Long에 대해서 왜 long은 안쓰는 건지 궁금해 알아보았다.우선 둘의 차이점은 간단하게 다음과 같다.Wrapper Classnull을 허용함Primitive Typenull을 허용하지 않음기본값 0Hibernat