현재 Plaything에서는 결제 요청에 transaction-id를 헤더에 넣어서 서버로 보내고 있는데, 서버는 이를 통해서 통일한 요청이 오면 중복 요청을 걸러내고 있다.
이때 레디스를 활용해서 transaction-id를 일정 시간만 저장하고 제거한다.
다만, 이렇게 하면 이용자가 매칭 요청을 여러번 누르는 경우에는 처리가 안된다. 그때마다 transaction-id가 달라질 것이기 때문이다.
실제로 우리는 앱이나 웹을 쓸 떄, 지연이 있으면 버튼을 연달아 누르기도 한다. 그때마다 결제가 된다면, 매우 큰 문제가 될 것이다.
특히 매칭 요청은 동일한 상대방에게 여러번 보낼 수 있다.
(물론, 일정 기간이 지나야 가능하다)
아예 a-b 매칭 기록을 유니크하게 잡아서 해결할 수 있는 문제가 아니다.
그래서, 이런 경우는 보통 어떻게 처리를 하는지 레퍼런스를 확인해봤다.
payment-lab 기술적 이슈 -2- 중복 결제를 막기위한 멱등키 생성.. 사용자가 결제를 확정짓는 시점은 언제일까?
이건 결제와 관련된 내용인데
여기서는 멱등키를 생성하는 방식에 대해서 고민하고있다.
이렇게 결제 페이지에 대한 고유한 값을 만들고, 그걸 저장해서 중복 결제 요청을 막는 방식이다.
나는 이 방식과 유사하돼, 현재 구조를 활용할 수 있는 방법을 고민해봤다.
우리는 매칭 요청을 보내면 Matching 테이블에 데이터를 쌓는다. 이때, 날짜를 기준으로 중복 여부를 처리하는 방식을 생각했다.
이는 비즈니스 로직을 고려한 설계이다.
1) 매칭 요청을 보낸 상대방에게 다시 매칭 요청을 보낼 수 있다
2) 대신 해당 매칭 요청 이후로, 매칭 프로필 조회를 하고서 프로필 50개를 skip(넘기기) 해야 매칭 요청이 가능하다.
이러한 비즈니스 로직이 있다.
그래서, 매칭 요청을 할 수 있돼, 너무 가까운 시일내로 요청을 다시 보내는 것을 막자(이걸 의도하지 않은 중복 요청이라고 판단했다)는 목표를 세웠다.
이미 매칭 요청을 할 때 요청자와, 수신자 정보로 그전 매칭 히스토리를 조회하고 있다.
여기서, 이제 매칭 정보가 db에 저장된 날짜를 기준으로 오늘 이미 매칭 요청을 보낸 게 있다면
중복된 요청으로 판단을 한다.
그러면, 클라이언트는 "중복된 매칭 요청입니다"라는 응답을 받게 되면서 의도하지 않은 중복 요청을 막을 수 있게 된다.
