03

GodLifeRouting

금융성 요청의 트랜잭션 신뢰성 설계

중복 요청과 동시성 충돌 방지

송금/정산처럼 중복 실행에 민감한 도메인에서 한 번 성공한 요청이 다시 처리되거나 잔액 업데이트가 겹치는 상황을 먼저 가정했습니다.

Problem Solving

문제 접근과 선택 이유

해당 프로젝트에서 예상한 문제, 버린 대안, 선택한 해결책을 면접에서 설명할 수 있는 흐름으로 정리했습니다.

문제: 같은 요청이 두 번 들어오거나 잔액 업데이트가 동시에 실행되면 사용자에게 바로 금전적 오류로 보일 수 있었습니다.
예상 리스크: API 재시도, 네트워크 중복 전송, 동시 잔액 업데이트가 부분 성공이나 잔액 불일치로 이어질 수 있었습니다.
접근: API 레벨의 중복 방지만으로는 부족하다고 보고, DB 제약과 트랜잭션 경계를 함께 설계했습니다.
해결: 멱등키, Unique 제약, 비관적 락, 단일 트랜잭션 경계를 적용해 같은 요청은 한 번만 처리되도록 했습니다.
선택 이유: 분산 보상 트랜잭션은 현재 범위에 비해 복잡도가 컸고, 단일 DB 트랜잭션으로 일관성을 보장할 수 있는 구조였습니다.
결과: 실패할 수 있는 지점을 코드 바깥의 DB 제약까지 포함해 막는 백엔드 설계 경험을 정리했습니다.

Flow

구조와 처리 흐름

복잡한 구현 세부사항보다 채용 담당자가 빠르게 이해할 수 있는 경계와 흐름만 남겼습니다.

GodLifeRouting 처리 흐름

Client request
  -> Idempotency key check
  -> Unique constraint
  -> Pessimistic lock
  -> Single DB transaction
  -> Balance / settlement result