如何設計一個 payment processor

今天幫我高中同學 mock 某家獨角 onsite 常出的這道 system design 題，他一時想不出來，就跟我說他不會。還好我去年十月去 AWS Summit 聽過一些 startup talks，他們在台上分享了他們用 AWS 解決問題的方法，使我受益匪淺。其中一家多倫多的 payment startup Pungle 就發表了他們用 AWS 解決 scalable, robust and secure real-time payment processing 的經驗，我就給他講了一遍，非常值得參考: https://youtu.be/_2i_-z-IiOk

給他 mock 過一遍之後，我才突然想到原來也可以藉由看 Amazon 上傳到 YouTube 的 real-world case studies 來學 system design。以下分享多倫多的 startup talks: https://www.youtube.com/playlist ... reG2Y6-8R0u7cN5lH63

2019-04-08 晚上補充：我覺得以 payment 來說，無論是個人對個人，個人對公司，或公司對公司都需要解決：
1. scalability (突然有大量的 requests 來時都可以即時處理)
2. reliability (盡量接近 100% availability + 失敗之後能後 retry)
3. timeliness (支付是有時間性的，最好能按照時間順序處理，這樣越早收到的交易可以越早完成)
4. no double spend (要是帳戶裡每一塊錢只能花一次)

樓主我是個新碼農，離開大學才工作了一年半，所以系統設計還沒弄太熟。想趁這個機會，總結一下我在公司裡（不是 payment 公司）在 AWS Summit 看到很多新創常見的 high level 解決方案：
1. 用 load balancer + auto-scale instances 來處理 surge in traffic。同時跑好幾個 instances 不僅可以增加 availability，當一個有 outage 其他 instances 可以幫忙頂替
2. 用一個 queue (e.g. AWS SQS) 來存放 failed jobs，instances 會從 queue 裡取出 failed jobs 再試一次。要是失敗太多次了可能就要放到另一個 queue (e.g. AWS DLQ) 然後丟 alerts 叫 ops 或工程師來看發生什麼事，手動處理，或是改 code 以後就不需要手動處理了
3. time sequencing 很重要，所以每個 job 可以放到 queue 或 event stream 裡 (e.g. SQS, AWS Kinesis or Kafka)，來個 producer-consumer pattern (producer 放 jobs 到 stream 裡，consumer 取出工作來做)
4. balance check + cache 正在處理的交易或把交易細節存在 database 裡，每看到一筆新交易都要檢查有沒有正在處理或已經處理完的同一筆交易
最後又回到 1. 最後如果需要 scale 更大，可以有 mutiple load balancers，multiple producer workers (instances)，multiple streams，multiple consumer workers (instances) 哈哈哈

要是地裡大神們剛好路過，希望能留下你們的看法和想法。我也好好奇 stripe，square，paypal，微信那些巨無霸公司是怎麼解決這個問題的，知道的朋友們希望你們能無私分享！謝謝！

lz知道stripe，square这样的公司，所以应该知道面试30分钟是不可能设计和描述一个完整的payment process系统的。这么一个系统，没有几百个功能，也有几十个。

系统设计的第一步，是和面试官商量，确定一个或两个或三个(不是四个或五个)功能，搞清要求，然后开始设计如何实现这些功能。功能性需求Functional requirements第一，功能设计Functional design第二，伪/实代码code and DB schema第三。这三个都完成了，才会触及到非功能性需求Non-functional requirements，诸如可靠性Reliability，可伸缩性Scalability，throughput， latency，availability(要几个9)，等等。

AWS 的customer architecture showcase 视频，主要是展现非功能需求在ASW上的实现方式，可以开拓视角但不能照搬。对工作没几年的申请人，面试是注重功能性需求的。回答系统设计问题的一个大忌就是上来就画一个load balancer，或者一个AWS的新服务功能。

14417335 发表于 2019/04/12 04:35:53


你说的很有道理。有个地方需要往细里走一走。数据库里存什么，是transaction的信息和一系列的状态。
因为wepay不应该是银行。就是一个中间商。而且这银行是多家的。比如A的是连着建行而B是...

银行的结算服务应该是异步的。银行的服务器应该只做一件事，就是把帐记下来，然后再通过异步服务来结算。毕竟对银行来说，不出错才是最重要的。

ericLaw 发表于 2019-4-12 03:10
美国公司很少有这个体量的支付需求，面试的时候还是要避免给自己挖坑。面试应该尽量从单机可以处理的数据 ...

你说的很有道理。有个地方需要往细里走一走。数据库里存什么，是transaction的信息和一系列的状态。
因为wepay不应该是银行。就是一个中间商。而且这银行是多家的。比如A的是连着建行而B是人行。
所以我们的数据库里每个transaction的状态要经历这样一个过程：

initialized   表示我方已经收到A要买B的东西的请求 下一站：要么withdrawn，要么failed

withdrawn     表示钱已经由A的银行账户进入我方（wechat）的银行账号。
              下一站：要么depositfailed要么succeeded

depositfailed 表示钱从我方（wechat）的银行账号没能进入B的账号。
              下一站：要么depositfailed，这时钱从A那里已经进入我方（wechat）
               的银行账号需要继续retry把钱放入B的账号。要么succeeded，要么failed

succeeded     表示A的钱已经进入B的账号。交易成功。通知用户A和B

failed        A的钱没有进入B的账号。交易失败。通知用户A和B

常出的這道 system design 題的题目大概是什么样子的。是类似微信付款的系统吗？

另外不知道商业支付的量和个人支付的量之间差距是几个量级？
商业本身的数目会比个人小。
商业的需求好像种类也很多。不少于逛商城的个人。
商业的支付有一定的平稳性。个人逢五一十一元旦春节的支付会呈现很强的spikes。

14417335 发表于 2019-4-8 21:23
常出的這道 system design 題的题目大概是什么样子的。是类似微信付款的系统吗？

另外不知道商业支付的 ...

我也不曉得商業和個人支付的 scale 差多少耶，非常好奇。

這種題目大概是說像 stripe 那種提供商家可以直接在網上接受信用卡或銀行帳戶支付的 API 和 backend 喔，不過其實設計微信支付也是個很好的系統設計問題。

把這裡的內容放到最上面補充去了 >  < 不好意思不知道怎麼刪掉這個多餘的回覆

tinlittle 发表于 2019-4-9 09:59
lz知道stripe，square这样的公司，所以应该知道面试30分钟是不可能设计和描述一个完整的payment process系 ...

你說得對耶！我得趕緊讓我高中同學想一下他該怎麼從你所給的 framework 來切入回答這題了。感激！

mark一下，感兴趣！！！！！！！！！！！！

payment其实是个频次相当低的服务。就算一天有1亿笔交易，一秒钟也才1000多个请求。也就是比一台数据库的连接上限多一点。如果是初步的设计，首先应该考虑怎样保证transaction的consistency以及错误恢复的措施。然后才是考虑规模化。

ericLaw 发表于 2019-4-10 02:21
payment其实是个频次相当低的服务。就算一天有1亿笔交易，一秒钟也才1000多个请求。也就是比一台数据库的连 ...

payment作为交易中间人是肯定的。但是是否也承担着银行的角色呢？一个transaction是由银行1，银行2，和WePay三方来参与吗？

假设一下场景。A从B那里买油条。微信先从A银行那里支出x元，然后放入B的银行，再通知双方支付完成吗？

银行在交易中承担什么承诺？

查了查：微信支付在2018年的日均总支付交易量超过10亿次

10 0000 0000次
86400秒
11500次/秒

假设银行的API为：
boolean withdraw(account_no, to_bank_routing, to_bank_account, amount)
boolean deposit(from_bank_routing, from_bank_account, account_no, amount)

每个transaction是个two phase commit

1. 
   
2. withdraw from buyer account to WeChat account
   
3. if failed, abort
   
4. // withdraw succeeded, amount is in WeChat account
   
5. deposit to seller account
   
6. if succeeded, return success
   
7. // deposit failed
   
8. deposite back to buyer account
   
9. return transaction failed.
   

复制代码