与谷歌工程师聊了1小时系统设计，做个总结吧

水橋こむぎ:
其实你如果愿意展开，每个点都能聊。但是展开之前要先跟面试官确认更具体的需求。 系统设计就好比面试官要你做一道鱼料理[吃瓜]你先要跟面试官确认，做红烧鱼还是糖醋鱼还是清蒸鱼，再确认一下做完鱼自己吃还是招待客人。然后你想从用啥调料展开也行，鱼在锅里煮多久展开也行。然而候选人回答时往往顺序反了，脑子里先想象一种鱼料理，没告诉面试官这个鱼料理是啥，就开始剖析这道鱼料理要用什么调料来调味。这也是系统设计题回答不好的原因[吃瓜] 所以，在峨眉山做鱼=系统设计技术面试，你说对吧海哥[吃瓜]

【回复】回复 @极海Channel :我这个急转弯水平如何[吃瓜]
【回复】回复 @问耳朵 :[吃瓜]嗨，各自表达自己观点挺好的，我很欢迎友善的交流，希望能多向你这样的前辈学习
【回复】电影明想好了我不是面神
悠影铃兰:
来做功课了 如果是常见的类似google doc这种 websocket做交互协议 把对文档的每一次或者一批操作抽象成一个个delta作为数据传输 后端这边有一些服务去维持住这些websocket 然后对文档做uuid分房间来进行广播 来实现共享修改和实时查看更改的功能 广播使用到的队列 锁啥的信息全部塞redis就行 然后按一定的间隔对文档的状态进行快照 把快照的信息入库到持久的数据库 一般文档这种归档用s3可能会多一些 重难点在于这个delta该如何设计 以及锁的策略等

【回复】目前很多在线文档的做法就是 当一个人编辑某一行的时候就直接把对应的那行锁死了不让人改
【回复】回复 @吕丶秀才 : 中心节点的问题是有些用户的体验是会受到牺牲的 因为这些用户到节点的链路完全不确定 所以才得走这种多节点共享状态的模式 毕竟自己搭的高速网总比外网可靠
【回复】互斥叠加的问题 看产品自己怎么想吧 两个方案 要么我们能检测到互斥 假设我们的delta做得好的话 就能像git那样 如果出现冲突一比较delta的hash就出来了 要么分支 要么强制使其中一个和另一个merge
来自大洋彼岸的小馒头:
已经全栈了，多听一下优秀架构师的设计思路[星星眼][星星眼][星星眼]

【回复】回复 @光荣火线使命 :啥都懂一点那叫全沾[笑哭]
【回复】回复 @极海Channel :全端就是后端懂点，前端也懂点
炁体源流徐楚岚:
不是！大过年的，我并不想听这些，我想听你跟她的故事！上一期不是说好了这期详谈的么？[doge]

南巷w1nd:
正要准备系统设计[打call]海哥太及时了[打call]

【回复】回复 @极海Channel :非常经典了[脱单doge]
【回复】[歪嘴]原题设计一个notion文档
旺财锦鲤:
pdf呢？或者word呢？赶紧写下来！！！——然后就是我的了[脱单doge]

【回复】回复 @极海Channel : 支持文字复制就行！[脱单doge]
【回复】回复 @极海Channel :可以改，原文件一份数据，增量编辑数据一份数据，导出下载这些场景把增量数据和原文件做diff，修改原文件即可
【回复】回复 @旺财锦鲤 :[歪嘴]很好回去等通知吧
我的小马达呀:
现实是现在很多项目都是外包的,需求得听甲方的,因为各种原因(不专业,系统间的依赖,甲方的甲方...)造成甲方自身都搞不清楚业务边界是什么.只能模糊的搞,后面不行了再加功能改东西.需求只能搞一个大概,很少在写代码之前能搞的很明确.

AI视频小助理:
本视频讲述了系统设计的面试题应该如何准备。只需要掌握两个步骤和一个原则，即可在讨论中展现自己的技术水平和业务理解。步骤包括确定业务边界和重点难点分析，原则是整个面试过程都在讨论中进行。详细设计阶段需要考虑横向和纵向两个角度。--以上内容由模型基于视频内容生成，仅供参考

是笑杨呀:
海哥，秒杀场景如何实现客户端与服务端时间同步呀

【回复】回复 @sky咕咚咕咚 :怎么同步[脸红]
【回复】客户端主动同步服务器时间
德邦总管斯奎因:
19年的office online server 还是文件一个连接单独一个流，这怎么搞？难道更新了？[笑哭]

水哥澎湃:
系统设计 - 面试 - 以设计在线文档为例 一个原则 应该是在讨论的过程中进行 两个步骤 1.确定业务边界. 需求评审 ...

光荣火线使命:
谷歌国外软件工程师几乎都是水货工程师

【回复】回复 @光荣火线使命 :我笑着看你评论[吃瓜]
【回复】回复 @光荣火线使命 : 我笑着看你评论[吃瓜]
【回复】回复 @光荣火线使命 :qs，还得是智能ide[doge]
Java陆总监:
事实上，这种面试过程太理想化。实际情况是你巴拉巴拉巴拉巴拉，面试官：嗯嗯嗯嗯嗯嗯。 你：xxxxxxx？ 面试官：我就是问你哎，你可以把你想到的都讲一下。。。 不可能吧面试变成架构讨论。。。或者说不太可能