멱등키 기반으로 중복 정산을 방지한 설계 경험
파트너사 정산 배치 시스템에서 네트워크 타임아웃으로 같은 정산 요청이 두 번 들어오는 사고가 발생한 적이 있습니다. 원인을 분석해보니 재시도 로직이 있는데 서버 측에 중복 방지 장치가 없었습니다. 이를 해결하기 위해 정산 요청마다 고유 멱등키를 발급하고, DB 유니크 제약으로 동일 키의 재처리를 원천 차단하도록 바꿨습니다. 적용 이후 6개월간 중복 정산 사고는 0건이었습니다.
면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.
파트너사 정산 배치 시스템에서 네트워크 타임아웃으로 같은 정산 요청이 두 번 들어오는 사고가 발생한 적이 있습니다. 원인을 분석해보니 재시도 로직이 있는데 서버 측에 중복 방지 장치가 없었습니다. 이를 해결하기 위해 정산 요청마다 고유 멱등키를 발급하고, DB 유니크 제약으로 동일 키의 재처리를 원천 차단하도록 바꿨습니다. 적용 이후 6개월간 중복 정산 사고는 0건이었습니다.
정산 금액에 대한 문의가 들어올 때마다 개발자가 로그를 뒤져야 하는 비효율이 있었습니다. 이를 개선하기 위해 정산 계산의 각 단계(원거래, 수수료율 적용, 공제 항목)를 별도 테이블에 스냅샷으로 남기는 구조로 바꿔, 특정 정산 건이 왜 그 금액으로 계산됐는지 SQL 조회만으로 확인 가능하게 했습니다. 이후 정산 문의 응대 시간이 평균 40분에서 5분으로 줄었습니다.
월 정산이 마감된 이후에 환불 등으로 금액이 바뀌는 경우가 종종 있었는데, 처음에는 이미 마감된 데이터를 직접 수정해 데이터 정합성이 깨지는 문제가 있었습니다. 이를 막기 위해 마감된 정산은 절대 수정하지 않고, 차액만큼을 다음 정산 회차에 조정 항목으로 반영하는 방식으로 바꿨습니다. 이렇게 하면 과거 정산 스냅샷이 항상 불변으로 유지되어 감사 추적이 깨지지 않습니다.
같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.
진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.