항해 플러스 4주차 회고

4주차 과제를 진행하면서 생긴 고민

콘서트 예약 프로젝트를 선정하고, 대기열 시스템을 구현하며 동시성 테스트를 작성했는데 통과하지 못하고 있다.

대기열 구현을 잘못한 것 같아서 지금 어떻게 해결해야 할지 고민하고 있다.

 

동시성 테스트 시나리오는 2가지로 구성

1. 여러 명의 사용자가 동시에 신청하는 경우

-> QUEUE_LIMIT 가 50인 경우, 100명의 사용자가 신청이 들어와도 50명의 사용자만 ONGOING 상태로 들어와야 한다.

2. 한 명의 사용자가 여러 번 신청하는 경우 

-> QUEUE 테이블에 한 번만 들어와야 한다.

 

1. 여러 명의 사용자가 동시에 신청하는 경우

이 시나리오는 ONGOING 상태의 카운트를 QueueService가 init 되는 시점에 OngoingCount를 가지고 와서 QueueOption 도메인에 AtomicLong으로 카운트를 관리하는 식으로 해결했지만, 멘토링 결과 AtomicLong으로 해결하는 것은 동시성은 통과되어도 분산 환경에서 적절하지 않은 것이라고 판단.

 

2. 한 명의 사용자가 여러 번 신청하는 경우 

아직 해결하지 못한 문제로 갈피를 못 잡고 있는 상황이다.

대기열을 로직을 우선적으로 다시 구현을 해야 할지 다른 로직부터 먼저 구현하고 진행을 해야 할지 고민이 된다.

 

위에 시나리오들을 해결하기 위해서 분산 환경 및 동시성 제어 키워드로 조금 더 공부를 해야할 것 같다.

 

3. 엔티티와 도메인을 분리해서 사용하는 경우 infra에서 조회했을 때 값이 없는 상태인 경우.. 

infra 계층에서 엔티티 조회 시 값이 없는 경우에 infra에서 EntitiyNotFoundException을 throw를 해야 하나?

service계층에서 throw를 하는 게 맞을 것 같다라고 고민을 했다.

 

멘토링 결과 : Infra에서 값이 없는 경우에 null로 service에서 return -> service에서 null check 하는 방식으로 권장하시는 것 같다.

 

이번 주를 마무리하며

이번 주에 대기열 도메인을 해결하기 위해 다양한 케이스와 예외사항을 생각하면서 정말 많은 시나리오를 구상했지만 결국은 FAIL..

다시 한번 작은 단위로 쪼개서 재구성을 해보는 시간이 필요할 것 같다.

 

위에서 시나리오를 통과하기 위해서 대기열 테이블에 대한 row를 insert를 하지 않고, 하나의 row로 update 하면서 userId에 대한 unique key를 만들어서 해결하는 시나리오로 고민을 해보고 재구성을 해봐야 될 것 같다.

 

다음 주차까지 까지 완벽한 구현을 위해서 파이팅!