멱등성, 중복 전달과 순서

Overview

멱등성은 같은 의도의 요청이나 Event를 여러 번 처리해도 최종 비즈니스 결과가 한 번 처리한 것과 같게 만드는 성질이다. 중복 제거는 한 구현 수단이고, 순서 보장은 별도 문제다.

핵심 용어

왜 필요한가

Network Timeout 뒤 Client는 서버가 실패했는지 성공하고 응답만 잃었는지 모른다. Broker도 Consumer 처리 후 Ack 전 Crash면 다시 전달한다. Retry를 금지하면 가용성이 떨어지고, 무작정 허용하면 이중 결제·이중 발송이 생긴다.

핵심 원리와 내부 동작

Event ID를 Consumer Inbox의 Unique Key로 Insert하고 업무 변경을 같은 Local Transaction으로 Commit한다. 이미 존재하면 성공적으로 Skip한다. 결제 API는 Client가 생성한 Idempotency Key에 요청 Hash와 결과를 연결해 같은 Key에 다른 Payload가 오면 거절한다.

Example

BEGIN;
INSERT INTO consumer_inbox(event_id, consumer) VALUES ('evt-7', 'shipping');
-- UNIQUE 충돌이면 이미 처리됨
UPDATE shipment SET status='READY', event_seq=12
WHERE order_id=42 AND event_seq=11;
COMMIT;

Affected Row가 0이면 중복인지, 이전 Event가 아직 안 왔는지 구분한다. Out-of-order는 잠시 보류 후 재시도하거나 상태 조회로 보정한다.

실무에서 발생하는 문제와 Trade-off

Dedup 보존 기간이 짧으면 오래된 Replay가 재처리된다. 무기한 보존하면 Table이 커진다. 결과 Cache 방식은 빠르지만 Payload 불일치 검사와 개인정보 만료가 필요하다. Global Ordering은 처리량과 가용성을 크게 낮추므로 정말 필요한 Business 범위만 직렬화한다.

흔한 오해

• HTTP PUT이 문법상 멱등이어도 구현이 매번 알림을 보내면 전체 효과는 멱등하지 않다.
• Kafka Producer 멱등성만으로 DB Side Effect의 중복이 사라지지 않는다.
• Timestamp는 Clock 차이 때문에 신뢰할 순서 번호가 아니다.
• “Exactly once” 표기는 시스템 경계를 명시하지 않으면 의미가 모호하다.

Production Considerations

Dedup Hit, Sequence Gap, 오래된 Event, Replay 건수와 처리 결과를 관찰한다. Key 생성 주체와 TTL, 요청 Hash, 응답 재사용 정책을 API 계약으로 둔다. Side Effect와 Inbox를 같은 Transaction에 넣고 Manual Replay 도구도 동일 규칙을 거치게 한다.

다른 사람에게 설명한다면

30초: “재시도와 At-least-once 전달은 중복을 만듭니다. Event ID를 Unique Inbox에 기록하고 업무 변경과 함께 Commit하면 같은 Event가 다시 와도 Skip할 수 있습니다. 순서는 Aggregate ID를 Partition Key로 쓰고 Sequence로 검증합니다.”

2분: Timeout의 불확실성, Inbox Transaction, Dedup 보존 기간, Global Ordering 대신 Aggregate Ordering, Sequence Gap 복구를 차례대로 설명한다.

Interview Questions

1. Idempotency Key와 Event ID의 차이는?
2. Inbox 기록과 업무 Update를 왜 같은 Transaction으로 묶는가?
3. 순서 역전을 어떻게 감지·복구하는가?
4. Exactly-once라는 표현에 어떤 경계를 물어야 하는가?

Related Topics

Transactional Outbox, Durable Outbox 운영 설계, 비동기 처리 설계, Kafka로 연결한다.