Closed jaejeong1 closed 1 year ago
"순번" 이라는 것을 통해 전체적인 메커니즘이 동작하는 것으로 보이는데요. 이 순번은 3.i 에 따라서 사용자가 전달해주는 것을 이용해서 판단(예약 서버로 포워딩을 할지말지 결정)목적으로 사용되는 것으로 이해됩니다. 이 경우 사용자가 보내주는 순번 정보가 조작되지 않았는지를 어떻게 확인할지 궁금하군요. (딱 드는 생각은 JWT token을 이용해서 위 문제를 해결할 수 있을까 싶군요)
예약을 위해선 클라이언트(웹)과 서버는 여러번의 API 통신을 하게될텐데요(목록조회, 예약, 예약 결과 조회 등) 위 대기 순번이라는 개념은 각 API가 아닌 유저별로 채번되겠지요?
만약 그렇다면 예약을 다한 유저의 경우에는(예약을 성공한 유저) 다시 예약 시도를 하면 대기열에 다시 줄을 서게될까요?
단순히 cutoff 미만의 유저를 예약 서버로 포워딩하게된다면 시간이 갈수록 예약 서버로 포워딩하는 유저의 수가 점점 늘어나지 않을까요?(cutoff 미만의 조건에 걸리는 유저의 수가 순증)
"순번" 이라는 것을 통해 전체적인 메커니즘이 동작하는 것으로 보이는데요. 이 순번은 3.i 에 따라서 사용자가 전달해주는 것을 이용해서 판단(예약 서버로 포워딩을 할지말지 결정)목적으로 사용되는 것으로 이해됩니다. 이 경우 사용자가 보내주는 순번 정보가 조작되지 않았는지를 어떻게 확인할지 궁금하군요. (딱 드는 생각은 JWT token을 이용해서 위 문제를 해결할 수 있을까 싶군요)
네, 말씀주신 대로 현재 아키텍처에서는 순번 정보를 검증하는 절차가 부재합니다. JWT를 사용해 검증하는 것이 가장 가볍고 정확한 방식으로 판단되어 해당 방법으로 순번 정보를 검증하는 로직을 추가해 아키텍처 보완할 예정입니다.
예약을 위해선 클라이언트(웹)과 서버는 여러번의 API 통신을 하게될텐데요(목록조회, 예약, 예약 결과 조회 등) 위 대기 순번이라는 개념은 각 API가 아닌 유저별로 채번되겠지요?
만약 그렇다면 예약을 다한 유저의 경우에는(예약을 성공한 유저) 다시 예약 시도를 하면 대기열에 다시 줄을 서게될까요?
네, 말씀주신 컨셉이 맞습니다!
단순히 cutoff 미만의 유저를 예약 서버로 포워딩하게된다면 시간이 갈수록 예약 서버로 포워딩하는 유저의 수가 점점 늘어나지 않을까요?(cutoff 미만의 조건에 걸리는 유저의 수가 순증)
이 부분은 cutoff 기준을 2개로 두어 처리하면 말씀주신 부분을 보완할 수 있을 것으로 보입니다. 예) cutoff_begin : 1000, cutoff_end : 1500 -> cutoff_begin : 1500, cutoff_end : 2000
당장 생각나는 성능 최적화 부분