Design Stripe - 결제 시스템을 승인으로만 설계하면 면접에서 왜 막히는가
돈의 흐름과 상태를 끝까지 맞추는 payment design의 실제 구조
Payment System - 결제 시스템
이번 글에서는 결제 시스템을 설계한다. 최근 몇 년 사이 전 세계적으로 전자상거래의 인기가 폭발적으로 증가했다. 모든 거래를 가능하게 만드는 것은 뒤에서 동작하는 결제 시스템이다. 신뢰할 수 있고, 확장 가능하며, 유연한 결제 시스템은 필수적이다.
결제 시스템이란 무엇일까?
위키피디아에 따르면, “결제 시스템은 금전적 가치를 이전함으로써 금융 거래를 결제하는 데 사용되는 모든 시스템”이다. 여기에는 그 교환을 가능하게 만드는 기관, 수단, 사람, 규칙, 절차, 표준, 기술이 포함된다.
결제 시스템은 겉으로 보기에는 이해하기 쉬워 보이지만, 많은 개발자들에게는 작업하기 두려운 영역이기도 하다. 작은 실수 하나가 상당한 매출 손실을 야기하고 사용자들 사이에서 신뢰를 무너뜨릴 수 있기 때문이다. 하지만 걱정하지 말자.
이 글에서 결제 시스템을 쉽게 풀어 설명한다.
1 . Understand Problem and Scope - 문제를 이해하고 설계 범위를 정하라
결제 시스템은 사람마다 매우 다른 의미를 가질 수 있다. 어떤 사람은 그것이 Apple Pay나 Google Pay 같은 디지털 지갑이라고 생각할 수 있다. 또 어떤 사람은 PayPal이나 Stripe 같은 결제를 처리하는 백엔드 시스템이라고 생각할 수 있다. 인터뷰 초반에 정확한 요구사항을 결정하는 것이 매우 중요하다. 다음은 인터뷰어에게 물을 수 있는 몇 가지 질문이다.
지원자
우리는 어떤 종류의 결제 시스템을 만드는 건가요?
면접관
Amazon.com 같은 전자상거래 애플리케이션을 위한 결제 백엔드를 만든다고 가정합시다. 고객이 Amazon.com에서 주문을 하면, 결제 시스템은 돈의 이동과 관련된 모든 것을 처리합니다.
지원자
어떤 결제 수단을 지원하나요? 신용카드, PayPal, 은행 카드 등인가요?
면접관
실제 환경에서는 결제 시스템이 이런 모든 옵션을 지원해야 합니다. 하지만 이 인터뷰에서는 신용카드 결제를 예시로 사용해도 됩니다.
지원자
우리가 직접 신용카드 결제를 처리하나요?
면접관
아닙니다. Stripe, Braintree, Square 같은 서드파티 결제 프로세서를 사용합니다.
지원자
우리 시스템에 신용카드 데이터를 저장하나요?
면접관
매우 높은 보안 및 컴플라이언스 요구사항 때문에, 우리는 시스템에 카드 번호를 직접 저장하지 않습니다. 민감한 신용카드 데이터 처리는 서드파티 결제 프로세서에 의존합니다.
지원자
애플리케이션은 글로벌 서비스인가요? 서로 다른 통화와 국제 결제를 지원해야 하나요?
면접관
좋은 질문입니다. 네, 애플리케이션은 글로벌이지만 이 인터뷰에서는 하나의 통화만 사용한다고 가정합시다.
지원자
하루에 결제 거래는 몇 건 정도인가요?
면접관
하루 100만 건의 거래입니다.
지원자
전자상거래 사이트가 매월 판매자에게 돈을 지급하는 pay-out 흐름도 지원해야 하나요?
면접관
네, 그것도 지원해야 합니다.
지원자
요구사항을 다 모은 것 같습니다. 제가 더 주의해야 할 것이 있을까요?
면접관
네. 결제 시스템은 많은 내부 서비스(회계, 분석 등)와 외부 서비스(결제 서비스 제공자)와 상호작용합니다. 서비스에 실패가 생기면 서비스들 사이에 불일치 상태가 생길 수 있습니다. 따라서 reconciliation을 수행해 불일치를 찾아 수정해야 합니다. 이것도 요구사항입니다.
이 질문들을 통해 기능 요구사항과 비기능 요구사항 모두에 대한 명확한 그림을 얻을 수 있다. 이 인터뷰에서는 다음을 지원하는 결제 시스템 설계에 집중한다.
Functional Requirements - 기능적 요구사항
Pay-in flow
결제 시스템이 판매자를 대신해 고객으로부터 돈을 받는다.
Pay-out flow
결제 시스템이 전 세계 판매자에게 돈을 보낸다.
Non-Functional Requirements - 비기능적 요구사항
신뢰성과 장애 허용성. 실패한 결제는 신중하게 처리되어야 한다.
내부 서비스(결제 시스템, 회계 시스템)와 외부 서비스(결제 서비스 제공자) 간 reconciliation 과정이 필요하다. 이 과정은 비동기적으로 이들 시스템의 결제 정보가 일관된지 검증한다.
Back-of-the-envelope estimation
대략적인 규모 산정
시스템은 하루 100만 건의 거래를 처리해야 한다. 이는 다음과 같다.
1,000,000 transactions / 10^5 seconds = 10 TPS10 TPS는 전형적인 데이터베이스에게는 큰 숫자가 아니다. 즉 이 시스템 디자인 인터뷰의 초점은 높은 처리량을 목표로 하기보다는, 결제 거래를 올바르게 처리하는 방법에 있다.
2. 고수준 설계 단계 - Design High-Level
고수준에서 결제 흐름은 돈이 어떻게 흐르는지를 반영하기 위해 두 단계로 나뉜다.
Pay-in flow
Pay-out flow
전자상거래 사이트인 Amazon을 예로 들어보자. 구매자가 주문을 하면, 돈은 Amazon의 은행 계좌로 들어오는데, 이것이 pay-in flow다.
돈이 Amazon의 은행 계좌 안에 있더라도, Amazon이 그 돈 전부를 소유하는 것은 아니다. 판매자가 그중 상당 부분을 소유하고 있고, Amazon은 수수료를 받고 돈을 보관하는 역할만 한다. 나중에 상품이 배송되고 돈이 해제되면, 수수료를 제외한 잔액이 Amazon의 은행 계좌에서 판매자의 은행 계좌로 흐른다. 이것이 pay-out flow다.
단순화한 pay-in과 pay-out 흐름은 아래 다이어그램에 나와 있다.
[단순화한 pay-in / pay-out 흐름]