장애 실험으로 검증한 결제 백엔드

ParityPay로 검증하는 결제 정합성

결제·원장 백엔드 ParityPay를 만들며 중복 요청, 동시 차감, 외부 응답 유실, 이벤트 중복 전달, 프로세스 재시작 아래에서 금융 불변조건을 어떻게 지켰는지, 실험이 찾아낸 결함과 측정의 실수까지 기록한 시리즈. 불변조건과 동시성, 외부 불확실성, DB와 메시지의 이중 쓰기, 원장과 대사, 브로커·외부기관·분산락 실험까지 열 편이다.

12개 글 2026.9 – 연재 중 GitHub 저장소

궁금한 것에 따라 들어가기

처음이라면 1편 → 2편. 무엇을 지키는지부터 Kafka와 이중 쓰기가 궁금하다면 5편 → 8편 장애 대응이 궁금하다면 3편 → 9편 → 10편

전체 편

불변조건 무엇을 지키고, 어디서 강제하는가

검증 가능한 불변조건 여섯 개를 세우고, 동일 지갑 경합의 원인을 추론이 아니라 측정으로 확정한 기록.

1. 1 장애가 나도 지켜야 할 금융 불변조건 여섯 가지 다음
2. 2 잠금을 필요 이상으로 오래 쥐고 있었다: 추론을 측정으로 바꾼 기록 다음

외부 불확실성 응답이 사라졌을 때

타임아웃을 실패로 확정하지 않는 UNKNOWN 상태와, 실험 27종이 문서와 테스트 밖에서 찾아낸 결함 12건.

1. 3 외부 승인 응답이 사라졌을 때: 타임아웃은 실패가 아니다 다음
2. 4 실험 27종이 찾아낸 결함 12건: 문서와 코드를 읽어서 나온 것은 하나도 없었다 다음

이중 쓰기와 원장 DB, 메시지, 기관 기록을 맞추기

Transactional Outbox와 멱등 소비자, 기관에 물어보지 못한 날을 구분하는 대사, 세 층에서 강제하는 이중부기 원장, 그리고 브로커·느린 외부기관·만료되는 분산락 앞에서 어떤 장치가 무엇을 막는지 직접 만들어 본 실험.

1. 5 DB 커밋과 Kafka 발행 사이: Transactional Outbox와 at-least-once 소비자 다음
2. 6 대사: "기관에 물어보지 못했다"와 "기관에 기록이 없다"는 다른 상태다 다음
3. 7 애플리케이션 코드를 믿지 않는 원장: 이중부기를 계정 체계, DB 제약, 속성 테스트로 강제하기 다음
4. 8 Kafka에서 중복·유실·순서 역전을 직접 만들어 보기: 멱등 소비자와 Outbox가 막는 것과 못 막는 것 다음
5. 9 느린 기관 앞에서 결제 서버를 지키기: 타임아웃, 재시도, 차단기, 리미터, 벌크헤드가 각각 무엇을 막는가 다음
6. 10 락 lease가 트랜잭션보다 먼저 끝나면 정말 정합성이 깨지는가: SETNX 락, Watchdog, fencing token, 그리고 락 없는 구조의 실측 다음

이어진 편

1. 11 지터는 언제 값을 하는가: 봉우리를 만들어야 보이는 것 다음
2. 12 실험 41종이 못 밟는 경로를 모델 검사가 5단계 만에 찾았다 다음