> For the complete documentation index, see [llms.txt](https://leehyokyun.gitbook.io/openbook/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://leehyokyun.gitbook.io/openbook/4-4..md). # 4-4. 멱등성 비동기적 흐름에서 필수적으로 고려해야 하는 상황, 멱등성에 대하여 ### 중복된 요청에 대한 일관된 처리 결과 보장 및 멱등성 분산 시스템 및 웹 애플리케이션 환경에서 동일한 요청이 여러 번 반복하여 유입되더라도 시스템의 최종 상태와 결과가 단 1번 실행되었을 때와 동일하게 일관성을 유지하도록 설계하는 원칙이 바로 멱등성이다. 사용자의 실수나 네트워크 재전송 등으로 발생하는 중복 요청을 안전하게 처리하기 위한 필수적인 아키텍처 요소이다. ### PRG (Post/Redirect/Get) Pattern 웹 브라우저 환경에서 수정 폼이나 데이터 등록 폼을 제출한 후 사용자가 새로고침(F5) 및 뒤로가기 등을 수행할 때 발생할 수 있는 비멱등적인 중복 요청 문제를 원천적으로 방지하기 위해 고안된 핵심 웹 아키텍처 패턴이다. 중복된 요청을 통한 잘못된 역등성 요청 및 데이터 훼손을 방지하기 위해 POST 요청 직후 웹 페이지를 즉시 Redirection을 진행하는 체계가 핵심 사상이다. 즉, POST 요청을 수신하여 비즈니스 처리를 마친 후 웹 서버가 브라우저에게 곧바로 결과 페이지를 바로 렌더링하여 응답하는 대신, HTTP 상태 코드 `302 Found` 등의 Redirection 응답을 제공하여 브라우저가 새로운 GET 요청을 통해 최종 우회 결과 페이지를 호출 및 응답하도록 제어한다. ### PRG 패턴 적용 여부에 따른 아키텍처적 메커니즘 비교 **PRG 패턴을 적용하지 않을 때 (X PRG 안쓸 때)** * **실행 흐름**: 브라우저의 POST 요청에 대해 서버가 즉시 결과 페이지를 직접 렌더링하여 응답(POST → 결과 페이지 응답)하는 구조를 취한다. * **사용자가 새로고침(F5)을 수행할 경우**: 브라우저는 직전에 보냈던 HTTP 메서드와 데이터인 POST 요청을 서버로 고스란히 재전송(POST 재전송됨)하게 된다. * **발생하는 문제점**: 이로 인해 서버 단에서는 동일한 주문이나 결제 로직이 연이어 반복 실행되어 주문이 2번 중복 생성되거나 결제가 2번 연속 처리되는 것과 같은 치명적인 데이터 정합성 파괴 및 장애 문제를 필연적으로 유발하게 된다. **PRG 패턴을 적용할 때 (PRG 쓸 때)** * **실행 흐름**: 사용자가 `POST /order` 형태로 주문 등록 요청을 보낸다. 서버는 해당 주문 처리를 정상 수행한 후 브라우저에게 `302 Redirect /order/success` 응답을 던진다. 이를 수신한 사용자의 브라우저는 즉시 `GET /order/success` 요청을 서버로 다시 자동 발행하며, 서버는 이 GET 요청에 대해 최종 성공 페이지를 안전하게 렌더링(POST → Redirect → GET)하여 반환한다. * **사용자가 새로고침(F5)을 수행할 경우**: 브라우저가 기억하는 직전의 요청은 POST가 아니라 최종 우회 경로인 GET 요청이 된다. 따라서 새로고침 시 `GET /order/success`에 대한 단순 GET 조회만 지속적으로 재요청하게 된다. * **확보되는 가용성**: 실제 데이터를 조작하고 변경하는 핵심 주문 및 결제 로직(POST)은 이미 이전에 완벽히 처리되어 분리되었기 때문에, 사용자가 성공 페이지에서 새로고침을 수백 번 반복하더라도 추가적인 데이터 왜곡 없이 시스템 상태가 매우 안전하게 보장된다. ### 본론적인 구조 설계에 따른 멱등성 확보 전략 #### Kafka, Redis 등 본론적인 구조 설계 * Kafka, RabbitMQ와 같은 처리권이 외부 체계에 있는 비동기 기반의 메시지 큐 체계는 기본적으로 Retry, DLT 등 특정 메시지의 중복 처리로 인해 멱등성 키 도입 등의 전략이 필요하다. * 이에 반해, Redis ZSet과 같이 구조적으로 중복을 제거할 수 있는 설계 구조를 취하여, 별도의 멱등성 키와 같은 복잡한 절차의 도입없이 비교적 간편한 방법으로 멱등성을 확보할 수 있다. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://leehyokyun.gitbook.io/openbook/4-4..md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.