1. FE는 POST /api/v1/payments 로 아래와 같은 request body를 포함하여 요청을 보낸다.

   {
       "productId" : 1,
       "quantity" : 1
   }
   

2. BE로 부터 202 Accepted status와 함께 아래의 response를 반환 받는다.

   {
       "productId": 1,
       "quantity": 1,
       "userId": 3,
       "seq": 7
   }
   

3. POST /queue/status seq와 product id를 request body에 보내서 전체 대기인원 수 및 현재 내 앞에 몇명이 있는지 response로 응답받는다. 1~3초 사이의 난수 값으로 ms 단위로 프론트엔드에서는 요청할 것 ( polling 부하분산)

   Request Body

   {
       "productId" : 1,
       "seq" : 7
   }
   

   Response Body

   
       {
           "ahead": ahead,
           "total": total_waiting,
           "status" : "WAITING"
           // "status" : "COMPLETED"
           // "status" : "FAILED"
       }
   

기본 아이디어 (네 시나리오 반영)

1. Gateway
   • 클라이언트 요청이 들어오면 토큰 검증 후 → Redis에 “대기열 티켓” 발급.
   • Redis INCR issued_seq → 전역 발급 번호.
   • ticket:{id} 해시에 seq, issued_at, TTL 저장.
   • 클라이언트한테 {ticket_id, seq} 반환.
2. Redis (임시 상태 저장소)
   • issued_seq / processed_seq 두 카운터로 전체 대기열 길이 관리.
   • ticket:{id} 해시로 개인 상태 관리 (TTL = 몇 분~몇 시간).
   • 영구 저장은 안 하고, DB는 실제 결제 완료 시점에만 기록.
   • 즉, Redis는 대기열만 책임지고, 결제 결과/이력은 RDS 같은 영구 저장소에 남김.
3. Payment-Service (Consumer)
   • Gateway가 “입장 허용된 티켓”만 SQS에 전달.
   • Payment가 SQS 메시지 처리 시작 시 INCR processed_seq.
   • 결제 완료 결과만 DB에 저장.