Lyft donation system

Lyft donation system


感觉面得不是很流畅。面试官一直在问我问题，我回答了，他又问，他估计会挂我。想请教一下大家这个题目。 requirements：
1. users donate to charity
2. donation confirmation
3. donations paid to charity
4. only 10 charity, this is hard coded.
5. Each donation event only last 24 hrs.  

面试中和面试官纠结的问题：
1. 我说需要存transaction history, 用来double entry account, 捐款结束后，我们可以验证金额。但是和面试官讨论之后，把这个去掉了。
2. 需不需要把钱先转到系统账户，最后选择直接转到charity账户
3. 需不需要exactly once 和idempotency, 面试官问我你怎么区别用户是刻意多次捐款还是错点。我说有两次点击，第二次只能点击一次，点多次肯定是错误点击
4. 我说如果按照charity_id做sharding, 会有hot shard problem. 面试官反复问这个，说我们只有5k QPS.
5. 我说要authentication, 他说只有24小时，用户不用注册，只留个邮箱就行了，所以不用authtication
6. SQL vs NOSQL
7. 问我为啥用message queue, 毕竟我们只有5k QPS, 我说有可能有traffic surge，还有可能是后台需要很长时间处理，所以用aync processing.
8. 我加了retry queue和 dead letter queue.  
9. 问我用哪种queue, 理由是什么。我说kafka, 我们可能要replay
10. 我说我们的payment service可以写入一个order message到kafka，然后3rd payment service读取，返回结果后写入kafka,然后我们的payment service读取结果。他问我这两个流程用一个queue吗？我说可以用一个server什么的不同topic.
11. 最后一分钟，我还说了用不用cache，决定不用（可能说错了），然后说了如何生成idenponency key, 然后说了sharding和加replica. 12. 没有时间写api和db scheme

补充内容 (2023-08-03 03:22 +08:00):

刚刚得到消息，因为这个面试跪了。

Payment System 兩篇必看文章
https://medium.com/airbnb-engine ... system-2981f6b070bb

https://underhood.blog/uber-payments-platform

我觉得你讲的没什么问题， 但是，你被drive了这个设计过程， 比如说哦， 你在讲用queue的时候，就应该讲用kafka，理由1，可以把消息存多天，可以handle traffic ，还可以retry。

我面试体验，一旦被持续challenging，基本上就是挂了。我能过的面试，都是没有或者很少chanllenging。

怎么看不见图片？再发一遍

leetcode有讨论，没看到很让人信服的设计:
https://leetcode.com/discuss/int ... tem-Design-question

希望大神指点

补充内容 (2023-10-15 06:52 +08:00):

I think they want to see how you address the 2 challenges:

• internal payment service handling 3rd payment providers---distributed transactions:
  . ensure idempotence while allow same donor to donate to the same charity multi times.  

    . able to recover from failures
    . scale independently

• it is for 3 days only, do not over-engineering.

Here is my solution:

• "Donation Service" is lightweighted; notification service is NOT time sensitive, so that they won't be bottleneck.
• "Payment Service" needs to make synchronized API calls, thus needs to be scalable.
• RDBMS is able to handle the volume, NoSql is a bit overkill; also need a standby RDBMS instance for HA
  
  Open to discussion, criticism :)
  

补充内容 (2023-10-15 06:54 +08:00):

Message queue 用kafka 不一定是好选择。rabbitmq 也有comfirm 机制。

你说选择Kafka的原因是要replay失败的消费，这个很多队列都可以，理由并不充分。而且Kafka没有dlq，你自己要手动实现。再来，你的traffic并不算太大，Kafka的高吞吐量优势发挥不出来

题外话：面试官这个5k qps不太可能啊，一秒5000个捐款请求，就算每个请求只捐1块，24小时下来就是4亿多的巨款… 最好确认一下，这个5k是峰值还是平均值

xfoursea 发表于 2023-10-14 14:56
怎么看不见图片？再发一遍

存donor info的时候，要存信用卡信息么？信用卡信息存在系统里会不会有什么问题？

skong03 发表于 2024-1-30 00:28
存donor info的时候，要存信用卡信息么？信用卡信息存在系统里会不会有什么问题？

理論上應該是不存 Credit Card 詳細訊息的，通常應該是 Service or Consumer 呼叫 Payment Service （如同 Stripe, Paypal）

比較常用的 Flow 如下：呼叫 Payment Service -> 取得一次性的 nonce token id -> 讓 User 用這個 nonce token id 去打開 pop up window 的 Payment Service 頁面，輸入信用卡訊息，完成捐獻 -> 然後真的完成後

-> 然後真的完成後，Payment Service 會叫 callback URL 去更新你 Service 的 Transaction Status

能感受出來樓主盡力想表達完整的 Payment Service ，我覺得這邊面試的重點感覺是怎麼處理 Exactly Once & Idempotent Key的問題