(COMAtching) AOP&Redis 활용 매칭 기능 멱등성 보장-2

AOP&Redis 활용 매칭 기능 멱등성 보장-2

COMAtching 프로젝트 운영중 생긴 멱등성 문제를 해결하는 과정에 대한 글입니다.
Stack: Spring-Boot, Java, Redis, HTTP

기존 구현에 대한 고찰

전 글에서 IETF의 가이드를 기반으로 POST메서드의 멱등성을 검증할 수 있는 AOP 기반의 검증 로직을 개발했습니다.

다음은 기존 구현의 에러 케이스들의 분기 기준입니다.

케이스 분기

상황	의미	응답
같은 키 + 다른 body	재사용된 키	422
같은 키 + 같은 body	중복 클릭	409

Q1. 현재 환경에서 정말 멱등한가?

같은 멱등키를 가진 경우에 대해서 이전과 같은 요청이었는지 아닌지에 대해서 오류를 다르게 처리해주는 것을 알 수 있습니다.

하지만 서버 입장에서 Client의 멱등키를 무조건적으로 신뢰한다는 것에 의문이 생겼습니다.

만약 버튼을 누를때마다 다른 멱등키가 생셩되는 클라이언트라면, 사용자가 1번의 요청을 의도했지만 2번 클릭된 경우에는 별도로 처리될 가능성이 있었습니다.

이런 시나리오를 생각해봤을때 클라이언트를 100% 신뢰하는 것은 어렵다고 생각했습니다.

Q2. 엄밀한 구분이 효율적인가?

또한 같은 key일 경우에 같은 내용의 요청인지 확인하기 위해서 body를 저장하면 byte로 저장되긴 하지만 기능에 따라서 같은 요청인지