강의

멘토링

로드맵

Inflearn brand logo image

인프런 커뮤니티 질문&답변

akakakakak님의 프로필 이미지
akakakakak

작성한 질문수

시스템 디자인 첫걸음: 면접에서 돋보이는 백엔드 아키텍처 설계하기

신뢰성

멱등성. '같은 요청'의 기준?

작성

·

109

0

같은 요청이 여러 번 들어와도 한 번만 처리하는 것.

 

여러 번의 요청이 들어왔을 때 이 요청이 '같은 요청' 이라는 것을 정확하게 판단할 수가 있을까요?

예를 들어 똑같은 점포의 똑같은 POS에서 똑같은 액수의 포인트 적립/사용이 두 번 들어왔을 때,

이 두 요청이 각자 다른 요청인지? 클라이언트 단의 문제로 인해 같은 요청을 두 번 보낸 것인지? 정확하게 판단할 수 있는 걸까요?

두 요청의 도착 시간 간격이 매우 짧을 때
-> 일반적인 상황에서 같은 동작이라고 판단할 수야 있겠지만.. 매우 빠르게 요청을 계속해서 받아야 하는 상황이라면?

도메인 특성에 따라 같은 요청임을 판단할 수 있는 기준이나 상황이 달라지기야 하겠지만 정확하게 보장 받을 수 있는 기준은 존재하기 어렵지 않나 하는 생각이 듭니다.

실제 사례를 통해 예시를 들어주실 수 있는 게 있을까요?

답변 1

0

성장랜턴님의 프로필 이미지
성장랜턴
지식공유자

안녕하세요, akakakak님.

말씀해주신 것처럼, 기존 필드의 조합만으로는 동일한 요청인지 정확히 판단하기 어려운 경우가 많습니다. 그래서 API를 설계할 때 멱등성을 보장하는 대표적인 방법은 클라이언트가 요청 시 고유한 키를 함께 보내도록 하는 것입니다.
이 외에도 시스템의 상태를 기반으로 멱등성 여부를 판단하거나, HTTP 메서드의 특성을 활용해 별도 처리가 필요 없는 방식도 있습니다.


  1. 클라이언트가 요청에 고유한 키를 함께 보냄 (멱등성 키)

예를 들어, 결제가 중복되지 않도록 하고 싶은 경우 클라이언트가 요청을 보낼 때 고유한 키(예: UUID) 를 만들어 함께 전송할 수 있습니다.
서버는 이 키를 기준으로 중복 요청 여부를 판단해, 이미 처리한 요청이라면 다시 처리하지 않습니다.

보통 서버는 이 키를 Redis 같은 캐시에 저장하고, 일정 시간 동안 유효하도록 설정해두는 경우가 많습니다.
(이 방식은 10강 '서버와 서버 간 통신' 마지막 부분에서도 언급되니 참고해주시면 좋습니다.)

 

  1. 상태 기반 처리

현재 시스템이 가진 데이터의 상태를 DB에서 확인해서 이를 기준으로 중복 요청 여부를 판단할 수도 있습니다.
예를 들어, 주문을 '배송중'으로 업데이트하는 API에서 주문 123번이 이미 '배송중' 상태라면, 같은 상태로 변경하는 요청이 들어왔을 때 중복 요청으로 간주해 처리하지 않을 수 있습니다.

 

  1. 서버의 동작이 HTTP 메서드의 멱등성 의도에 맞게 구현

HTTP 명세에서 PUT, DELETE, GET 등의 메서드는 같은 요청을 여러 번 보내도 같은 결과가 나와야 한다는 멱등성을 가진 요청입니다. 이 의도가 서버 API에 정확히 구현되어 있다면, 별도 처리 없이도 자연스럽게 멱등성이 보장될 수 있습니다.

예를 들어, S3 같은 오브젝트 스토리지에 파일을 업로드할 때 'PUT /file1'처럼 같은 경로로 파일을 여러 번 업로드하더라도 기존 파일을 덮어쓰기 때문에 결과는 항상 같습니다.


모든 API가 멱등성을 반드시 보장해야 하는 것은 아니므로,
API의 역할과 도메인 특성을 고려해 필요한 경우에는 위 방법들 중 적절한 방식을 선택해 적용해줄 수 있습니다.

akakakakak님의 프로필 이미지
akakakakak

작성한 질문수

질문하기