1. 요구사항 정리
•
아마존과 같은 전자 상거래 애플리케이션을 위한 결제 시스템을 만든다 가정
•
직접 결제 처리가 아닌 서드파티 시스템 이용
•
페이-인 흐름 = 결제 시스템이 판매자를 대신해 고객으로부터 대금 수령
•
페이-아웃 흐름 = 결제 시스템이 전 세계의 판매자에게 제품 판매 대금 송금
•
결제 실패는 신중하게 처리
•
내/외부 시스템간 정보가 일치하는지 비동기적으로 확안
1.1. 규모추정
•
하루 100만 건의 트랜잭션 처리 가정
•
1,000,000 / 10^5 = 10 TPS
2. 청사진 그리기
•
이 시스템에서 제일 중요한건 대금의 라이프사이클이다.
2.1. 대금 수신 흐름
•
결제 서비스가 모든 시스템의 프로세스를 조율한다.
•
결제 실행자는 서드파티를 실행한다.
•
원장은 결제 트랜잭션 내역을 모두 보관한다.
◦
오류 발생시 봐야한다! 매우 중요!!
•
지갑은 판매자의 계정 잔액을 기록한다.
◦
혹은 특정 사용자가 결제한 총 금액을 기록할 수 있다.
2.1.1. 결제 서비스 데이터 모델
•
당연하지만 안정성이 매우 높고 인력 구하기 까다롭지 않아야 하며 숙련자가 있어야만한다.
◦
각종 관리에 필요한 도구가 풍부해야 한다.
◦
3가지 조건을 들으면 RDB밖에 떠오르지 않는다.
2.1.2. 복식부기 원장 시스템
•
Double-entry라는 아주 중요한 설계 원칙
•
결제 시스템에 필수이며 정확한 기록을 남기는 데 핵심적 역할을 한다.
◦
하나의 계좌에선 증가가 다른 하나의 계좌에서는 차감이 이뤄져야 한다.
•
이 시스템 사용 시 결제의 시작과 끝까지 추적 가능하다.
2.1.3. 외부 결제 페이지
•
신용카드와 결제는 보안과 법과 같은 까다로운 부분들이 많다.
•
그러니까 외부 결제 시스템임 PSP에게 이를 떠넘기는게 제일 현명하다.
3. 상세 설계
3.1. PSP 연동
•
PSP와 결제 시스템은 토큰과 난수값을 통해서 결제를 식별할 수 있다.
•
난수 값은 결제 번호가 된다.
•
결제 토큰은 추후 웹훅을 통해서 이벤트 전달 시 해당 토큰으로 결제의 유무를 파악가능하다.
3.2. 조정
•
비동기적으로 시스템이 통신하는 경우 메시지가 전달되거나 응답이 반환된다는 보장이 없다.
•
정확성을 조정하기 위해서 주기적으로 서비스간 상태를 비교하여 일치하는지 확인하는 작업을 거친다.
◦
예를 들어 매일 밤 PSP나 은행에게 정산 파일을 받아 결제 시스템과 비교한다.
3.3. 결제 지연 처리
•
PSP가 결제 위험성이 높다고 보고 담당자 검토를 요구하는 경우
•
신용 카드사가 추가 정보를 요청하는 3D 보안 인증을 요구하는 경우
•
대응 방법
◦
사실 위에서 일어난 모든 일들은 PSP가 처리해야 하는 일들이고 우리는 웹훅을 기다리면 된다.
◦
때론 웹훅 대신 폴링 하도록 권장하는 PSP도 있다.
3.4. 내부 시스템 통신
3.4.1. 동기 시스템
•
성능이 저하되고, 장애 발생 시 격리가 곤란해지고, 결합도가 높아지며, 확장성도 낮아진다.
•
단점밖에 없네? 팽!
3.4.2. 비동기 통신
그래 이 맛이지
•
메시지 큐를 통해서 내부 시스템 통신을 진행한다.
•
단일 서비스가 이를 받아 처리하는 경우 메시지는 한번 받으면 사라진다.
•
다중 시스템에서 이를 받아서 사용하는 경우 여러 시스템에서 메시지를 받아 사용할 수 있다.
3.5. 결제 실패 처리
•
결제 상태 추적
◦
실패 이유를 파악하고 재시도 해야한다.
3.6. 이중결제 방지
•
결제 시스템에서 제일 주의해야할 것은 이중결제다!
•
때문에 시스템은 정확히 한 번만 전달해야 한다!
3.6.1. 재시도
•
즉시 재시도(immediate ret1Y): 클라이언트는 즉시 요청을 다시 보낸다.
•
고정 간격(fixed intewal): 재시도 전에 일정 시간 기다리는 방안이다.
•
증분 간격(incremental intewal): 재시도 전에 기다리는 시간을 특정한 양 만큼 점진적으로 늘려 나가는 방안이다.
•
지수적 백오프(exponential backoff): 재시도 전에 기다리는 시간을 직전 재시도 대비 두 배씩 늘려 나가는 방안.
◦
예를 들어, 요청이 처음 실패하면 1초 후에 재시도하고, 두 번째로 실패하면 2초, 세 번째로 실패하면 4초를 기다린 후 재시도한다.
•
취소(cancel): 요청을 철회하는 방안. 실패가 영구적이거나 재시도를 하더라도 성공 가능성이 낮은 경우에 흔히 사용되는 방안이다.
3.6.2. 멱등성
•
멱등성은 수학 또는 컴퓨터 과학적 연상이 가질 수 있는 한 가지 속성으로 여러번 실행되어도 최초 실행 결과가 그대로 보존되는 특성
•
UUID를 통해서 멱등성을 확보하는 경우가 많고 권장된다.
