一篇文章解决所有system design面试

謝謝分享 sys design ~~!

lz关于ood有没有分析？加米

aunom 发表于 2020-12-05 22:55:03
uber 的那个介绍 cherami 的文章我看了，没看出来和 Kafka 比有什么优势，不明白为什么造了这么一个轮子。更骚的是 uber 现在自己也不维护了，好像是接着用 kafka 了

对那个系统估计是我为了冲kpi哈哈哈 但是不影响它作为系统设计面试的答案，或者你也可以直接去看kafka的实现，就是不知道有没有很好的相关文章了

好帖我顶

Thanks for sharing~~

请问google doc的文章是哪个呀？google了半天没搜到
昨天考了这个，只照着youtuber讲的答得，觉得细节答得不好。。concurrency的问题觉得处理的不好。
楼主一般搜索啥关键词呢？我搜system design 或者 artitecture感觉有效信息好少啊

我想要offer真的 发表于 2020-12-16 22:45:51
请问google doc的文章是哪个呀？google了半天没搜到
昨天考了这个，只照着youtuber讲的答得，觉得细节答得不好。。concurrency的问题觉得处理的不好。
楼主一般搜索啥关键

搜design collaborative document system, gg 自己有个讲座还有好多篇相关的论文

yuyahome 发表于 2020-12-18 05:54
搜design collaborative document system, gg 自己有个讲座还有好多篇相关的论文

谢谢你啊！这名字我还真的想不到。。。其实我经常在google搜，比如recommendation system都是些垃圾信息。谢谢！

感谢分享如此有用的信息！

yuyahome 发表于 2019-10-15 11:24
是这篇。 那个失败了的话是stripe/bank的责任，多扣了钱也是他们的责任我们airbnb不用也不应该关心

补充 ...

我个人的理解，这个blog解决的是提供一个framework让payment相关的request都变成idempotent，通过在db记录transaction以及rpc 是否retryable，这样client可以safely assume idempotent。但是如果在post rpc阶段 发生了system crash（server side from airbnb），这个系统记录的transaction并不能包含rpc的side effect的信息，比如这个charge是否已经发生了，因为还没来得及记录system crash就发生了。这个blog的评论区里作者也回复了很多人关于这个问题，要彻底的解决double charge单靠这一个系统是不够的，至少还需要其他的方式去query payment side得到更多的信息。
简单来说我并不认同这个失败了完全是stripe/bank的责任。关于这个system crash during payment的问题，我之前找到过一个dropbox的blog，希望能对大家有所帮助：
https://dropbox.tech/infrastruct ... yment-communication

顺便求加米
补充一下，这个文章里的downstream rpc并不一定是idempotent的，这也是为什么需要记录retryable和nonretryable的原因