h**o
发帖数: 548 | 1 上周面了个小公司，问了个System design 题：
有个网站（下称我的网站）本周末允许任何人捐钱给指定组织. How to design the
web server and back end?
我大致说了下。然后又问：
1. 捐钱可用各种方式，paypal, credit card, bank account, etc. 此网站如何实
现？
我不知道一般网站怎么实现付款的，请问怎么答，是不是paypal或相应credit card,
bank 公司各自有API 让网站call 还是怎么的？
2. 那要paypal之类当了怎么办? 我的网站返回error还是怎么的?
3. 我的网站可不可以存捐助者信息？例如姓名，捐给谁，信用卡等？
4.信息存哪？是central DB or distributed DB?
5.当我的网站和payment system交互时，我的网站和用户之间在干吗？（我猜可能用户
发http post form 后我的网站就会一个response 说正在处理请等待，然后让用户poll
付款结果什么的，具体我也不大清楚）
6.如果我的网站用message queue, 用几个queue 呢？如果用多个queue如何做到FIFO如
果有FIFO的要求？（我说message 里加seqNo之类的）如果queue 死了怎办？我说每个
queue要有个backup queue. 又问 How? 我说那每个queue定时copy个backup...然后开
始胡说八道了。
7.If DB becomes large, what to do? 我说就distributed， sharding..
好久没面了，也没准备，感觉不大好。如果面的是你，你如何回答这几个问题？特别是
1，2，3，5，6 |
s****3
发帖数: 270 | |
m******e
发帖数: 82 | 3 我也被面到这个系统设计，feedback是very strong。我也不知道他们评判标准是什么
，就是按部就班从前端服务层数据库回答，design for scalability，design for
failure。比如有一个问题是钱暂时保存在本网站的账户，每周五定时转给慈善组织，
如果此时转钱失败了怎么办，如何保证不多扣不少扣。
对了，我说用stripe这样的第三方接口转账。 |
m******e
发帖数: 82 | 4 还是认真回答一下吧：
1. 你可以设想每个银行开放自己的接口，可以操作credit/debit card，在你的系统中
可以抽象一层，对外暴露统一接口，对内处理各种银行。以后有了新的银行就可以在接
口不变的情况下扩展。这时你会发现其实外面有这样的服务了，比如stripe。
2. 直接返回错误用户体验太差，可以添加重试机制，异步扣款，扣款成功邮件提醒。
3. 这是一个compliance问题，涉及法律问题，应该由business的人决定，当然保存了
之后下次再捐款可以很便捷。
4. 不同数据存不同数据库，像个人信息，卡信息可以存rdbms。一些activity之类的可
以存nosql。
5. 要么同步，要么异步，自己分析
6. 用不用queue跟业务量和业务逻辑有关，如果要用就上kafka
7. 数据库变大影响是索引变大，查询更新速度变慢，所有你能想到的优化都说一遍，
比如sharding，read replica，caching |
r*****s
发帖数: 1815 | 5 重试机制 - 要注意idempotency - 这里细节上还是要注意的，比如用户端到你的服务
端的idempotency如何保证 (i.e. 为什么支付页面都不让刷新)
transaction 和 recovery - WAL, two phase commit
latency完全不重要，随便怎么玩
最后关于你提到的compliance，我感觉存信用卡信息是一个非常严肃的事情，需要咨询
legal和security |
h**o
发帖数: 548 | 6 Thanks mknoodle. 你确实很strong.
6 的 queue 用 kafka 不能绝对FIFO。aws sqs 据说可以。如果是其它queue, 我觉得
可以 给 message seqNo
然后 consum每次取所有queue中最小seqNo那个message.
queue 要死了怎么办？kafka 有 replication 机制。不是很懂。大致是每个message
在其它queue 有备份。
【在 m******e 的大作中提到】
: 还是认真回答一下吧：
: 1. 你可以设想每个银行开放自己的接口，可以操作credit/debit card，在你的系统中
: 可以抽象一层，对外暴露统一接口，对内处理各种银行。以后有了新的银行就可以在接
: 口不变的情况下扩展。这时你会发现其实外面有这样的服务了，比如stripe。
: 2. 直接返回错误用户体验太差，可以添加重试机制，异步扣款，扣款成功邮件提醒。
: 3. 这是一个compliance问题，涉及法律问题，应该由business的人决定，当然保存了
: 之后下次再捐款可以很便捷。
: 4. 不同数据存不同数据库，像个人信息，卡信息可以存rdbms。一些activity之类的可
: 以存nosql。
: 5. 要么同步，要么异步，自己分析
|
h**o
发帖数: 548 | 7 多谢。厉害啊！学习了。
【在 r*****s 的大作中提到】
: 重试机制 - 要注意idempotency - 这里细节上还是要注意的，比如用户端到你的服务
: 端的idempotency如何保证 (i.e. 为什么支付页面都不让刷新)
: transaction 和 recovery - WAL, two phase commit
: latency完全不重要，随便怎么玩
: 最后关于你提到的compliance，我感觉存信用卡信息是一个非常严肃的事情，需要咨询
: legal和security
|
