백엔드 멱등성과 재시도 설계 원칙
그래서 멱등성은 특정 API 옵션이 아니라 재시도 가능한 시스템을 만들기 위한 기본 설계 원칙입니다.
멱등성과 재시도는 같이 봐야 한다
재시도는 신뢰성을 높이지만, 멱등성이 없으면 같은 요청이 여러 번 적용됩니다. 반대로 멱등성만 강조하고 재시도 경로를 설계하지 않으면 실패 복구가 약해집니다.
좋은 설계는 다음을 함께 다룹니다.
- 어떤 연산이 중복 실행될 수 있는가
- 중복을 어떻게 식별할 것인가
- 최초 성공 결과를 어떻게 재사용할 것인가
- 부분 성공 상태는 어떻게 복구할 것인가
즉 멱등성은 함수형 개념이 아니라 운영 안정성을 위한 경계 설계입니다.
멱등 키는 저장만 하면 끝나지 않는다
많은 팀이 Idempotency-Key 헤더를 도입하고 안심하지만, 실제로는 저장 전략이 더 중요합니다.
- 요청 본문과 키의 조합을 검증할 것인가
- 키 보관 TTL은 얼마나 둘 것인가
- 실패 응답도 재사용할 것인가
- 진행 중인 요청과 완료된 요청을 어떻게 구분할 것인가
같은 키로 다른 요청 본문이 들어오는 경우를 허용하면 오히려 더 위험합니다. 키와 의도를 함께 묶는 검증이 필요합니다.
데이터베이스 제약이 마지막 안전망이다
애플리케이션 레벨 체크만으로는 경쟁 조건을 모두 막기 어렵습니다. 결국 유니크 키, 상태 전이 제약, 업서트 같은 데이터베이스 보호 장치가 함께 있어야 합니다.
예를 들어 주문 생성이나 결제 승인처럼 중복이 치명적인 작업은 다음 조합이 효과적입니다.
- 클라이언트 또는 업스트림이 전달한 멱등 키
- 서버 측 요청 기록 저장
- 유니크 인덱스 또는 자연 키 기반 중복 방지
- 이미 처리된 결과의 재사용
애플리케이션 로직과 데이터베이스 제약이 같은 방향을 보지 않으면, 트래픽이 몰릴 때 중복이 새어 나갑니다.
비동기 소비자도 반드시 멱등해야 한다
HTTP API만 멱등하게 만들고 큐 소비자는 소홀히 하는 경우가 많습니다. 하지만 메시지 시스템은 적어도 한 번 전달을 전제로 하는 경우가 많기 때문에 소비자 멱등성은 더 중요할 수 있습니다.
- 메시지 ID 기반 처리 이력 저장
- 이미 처리한 이벤트 재적용 방지
- 상태 전이 중복 적용 방지
- 외부 시스템 호출 전후 보상 전략
특히 이메일 발송, 포인트 적립, 재고 차감 같은 사이드 이펙트는 중복 실행 시 비용이 바로 드러납니다.
”재시도 가능”과 “무제한 재시도”는 다르다
재시도는 정책이 있어야 합니다.
- 어떤 오류만 재시도할 것인가
- 최대 횟수와 백오프는 무엇인가
- 회로 차단이나 데드레터는 있는가
- 사용자가 같은 버튼을 반복 클릭할 때 UX는 어떤가
멱등성이 있다고 해서 무제한 재시도가 안전한 것은 아닙니다. 비용이 큰 연산은 재시도 자체를 조심해야 하고, 결국 비즈니스 의미와 함께 설계해야 합니다.
마무리
멱등성은 분산 시스템에서 예외적인 고급 기능이 아닙니다. 재시도, 중복 전송, 부분 실패가 기본인 현실을 견디기 위한 최소한의 설계입니다. 좋은 백엔드 팀은 멱등 키만 추가하지 않고, 저장 전략, 데이터베이스 제약, 비동기 소비자 처리, 재시도 정책을 함께 설계합니다. 결국 멱등성은 “한 번만 실행된다”는 환상을 버리고, 여러 번 와도 같은 결과를 만들 수 있게 만드는 일입니다.
Continue Reading
다음으로 읽기 좋은 글
비동기 작업 API의 멱등성과 상태 제어
긴 작업을 HTTP 요청 하나로 끝내지 않고 작업 생성, 재시도, 취소, 결과 조회까지 안정적으로 설계하는 방법을 정리합니다.
⚙️ BackendAPI Idempotency Key 생명주기 설계
프로덕션 API에서 idempotency key의 생성, 저장, 만료, 재사용 동작을 어떻게 설계할지 정리합니다.
🗄️ DatabaseIdempotent Backfill 체크포인트 설계
백필은 한 번에 끝나지 않는 경우가 많습니다. 중단과 재시작을 견디는 체크포인트 설계가 데이터 작업의 안정성을 좌우합니다.
💬 Language타입 안전성과 런타임 검증의 경계
타입 시스템이 강해질수록 런타임 검증을 잊기 쉽습니다. 실전 서비스에서 타입과 검증의 경계를 어떻게 나눌지 정리합니다.
다음 탐색