멱등성 키는 얼마나 오래 보관해야 할까

멱등성 키를 저장하면 중복 요청을 막을 수 있지만 키를 언제 지울지가 남습니다. 너무 빨리 지우면 늦은 재시도가 다시 실행되고, 너무 오래 두면 저장 비용과 재사용 충돌이 커집니다.

데이터 흐름의 경계를 확인한다

키의 유효기간은 네트워크 재시도, 큐 재전달, 클라이언트 오프라인 복구 시간을 고려해 정합니다. API 요청과 비동기 작업은 재시도 창이 다를 수 있습니다. 단일 TTL을 모든 업무에 쓰기보다 결제·알림·파일 처리별로 분리합니다.

실패와 중복 처리를 정한다

같은 키로 다른 본문이 오면 이전 결과를 돌려주지 말고 충돌로 처리해야 합니다. 요청 본문의 안정적인 해시와 실행 상태를 함께 저장합니다. 처리 중·성공·실패를 구분하지 않으면 동시 요청에서 둘 다 실행될 수 있습니다.

작은 범위에서 재처리한다

키의 범위를 사용자나 테넌트에 묶습니다. 다른 고객이 우연히 같은 문자열을 사용해도 요청이 섞이지 않아야 합니다. 외부 API와 내부 이벤트에서 같은 업무를 여러 번 처리하는 경우에는 전체 처리 흐름의 식별자를 연결합니다.

지연과 불일치를 관측한다

키 충돌률, 보관 기간이 지난 뒤의 재시도, 저장소 크기, 중복 실행 건수를 봅니다. 실패가 재시도 가능한 실패인지 영구 실패인지 구분해야 재사용 정책을 정할 수 있습니다. 오래 걸리는 작업은 TTL보다 작업 완료 시간이 길어질 수 있습니다.

복구 절차를 유지한다

멱등성은 ‘항상 한 번만 실행’의 마법이 아닙니다. 같은 논리적 요청을 서로 다른 키로 보내면 중복을 막지 못합니다. 클라이언트가 키를 생성·보관하는 규약과 운영자의 수동 재처리 절차까지 맞춰야 합니다.

현장에 적용할 때의 순서

1. 업무별 최대 재시도 창 측정
2. 키·본문 해시·상태 함께 저장
3. 테넌트 범위와 동시 요청 처리

주의할 실패: TTL만 설정하면 중복이 끝난다고 믿기

관찰할 지표: 만료 후 재시도·충돌·중복 실행

적용 전 체크리스트

• 업무별 최대 재시도 창 측정
• 키·본문 해시·상태 함께 저장
• 테넌트 범위와 동시 요청 처리

참고 자료

AWS Powertools — Idempotency. 멱등 처리의 키·상태·만료 개념은 AWS 공식 문서를 참고했습니다. 업무별 보관 정책은 적용 제안입니다.

이미지와 도식은 이해를 돕기 위한 개념 시각화입니다. 특정 고객의 실제 설비·데이터·화면을 재현한 것이 아닙니다.

#멱등성키 #중복요청 #API설계 #재시도 #TTL #네이처프랙탈 #시스템설계 #서비스운영 #안정성 #데이터활용