서비스 설계를 정리하는 과정에서

몇가지 이상해보이는 점들이 발견되어서 아래처럼 설계를 수정해야할 것 같다고 생각이 들었는데요..!

한번 읽어보시고 피드백 주시면 감사합니다! ㅎㅎ - Parrot

서비스 설계 변경사항

활성 토큰 발급 위치 변경 : 티켓 예매 서비스(WAS) -> 대기열 서버

기존 설계에서는 활성 토큰을 발급하는 역할을 티켓 예매 서비스(WAS) 가 맡고 있었는데,

**활성 토큰 발급 권한은 “대기열 서버”**가 가지는 것이 적합해보인다.

• 대기열 서버의 책임은 WAS로 들어갈 수 있는 사용자를 통제하는 것이고,
• **티켓 예매 서비스(WAS)**의 책임은 단순히 들어온 사용자가 합법적인지만 확인하고 예매 처리하는 것이다.

토큰 발급을 WAS가 하는 경우, 새로운 사용자가 활성큐에 유입된 이후에 토큰 발급 로직 처리를 위해서

WAS 가 활성큐를 직접 바라보거나 대기열서버 -> **티켓 예매 서비스(WAS) 로 K유저 토큰 처리해줘!**메시지를 전달해줄 필요가 있었다.

하지만 이 경우는 티켓 예매 서비스(WAS) 가 대기열 서버를 알고 있어야해서 결합도가 높아진다는 단점이 있다.

게다가 WAS가 느려지면 → 토큰 발급도 느려짐 → 입장 속도도 같이 느려진다.

하지만**,** 활성 토큰 발급 책임을 티켓 예매 서비스(WAS) -> 대기열 서버 로 이동함에 따라 이제 티켓 예매 서비스(WAS)가 더이상 대기열 서버를 몰라도 된다. 티켓 예매 서비스(WAS)는 대기열 서버에서 발급해준 토큰을 검증하고 API를 처리하는 책임만 맡으면 된다.

왜냐하면 대기열 서버에서 WAS가 수용할 수 있는 인원 수 만큼 활성큐를 유지해주기 때문이다.

• 활성 토큰 = 현재 WAS 수용 가능한 인원 안에 들었다는 증거이고

• 대기열 서버가 이 토큰을 가지고 있는 사용자 숫자를 수용 한계 이하로 유지해주기 때문에

• 대기열 서버가 알아서 인원 조정해줄 것을 믿고 서버 로직 처리에만 집중하면 된다.

  

메시지 큐 : Redis Pub/Sub 은 적절한 선택이었나?

부제 : RabbitMQ vs BullMQ vs AmazonSQS vs kafka vs Redis Pub/Sub