从面试官+real world角度谈如何搞定系统设计 (别被某些热门教程误导了)

面了一些intermediate和senior level的system design，发现一些面试者被网上某些fancy教程搞得误入歧途，前期准备并不靠谱，想分享下自己的心得。欢迎大家给米奖励哈哈。


首先最常见的就是上来就垒一些当下最流行的tech stacks，以及非常时髦的新技术，反正怎么炫酷怎么来。这种情况在我眼里很可能就是没有实战经验纯粹纸上谈兵的redflag。毕竟system design是模拟实际工作中的项目，如果我让你设计一个generic customer facing feature，需要去关注load balance，k8s cluster，network mesh等这些底层的infra吗？这些基本都是假定infra team已经提供了。设计更多是关注这个product本身，而不是放一些fancy的技术。有些功能确实可能被cloud service给实现了，但是设计本身考的是你如何去实现他，而是不是考你对时髦技术的了解程度。这就像算法面试要是考二分法，你可以直接call built in functions，但这就是没有面试的意义了。更何况在现实工作中，大部分公司的tech stack都不是那么自由，不是说你想选哪个fancy database就可以直接support的😂😂


回到重点，那么系统设计重点是考什么？我想你要是有实际工作开发新功能的经验，都会明白在真实的design当中，tech stack和cloud service的选择很有限，作为product team更多关注的是data model design和API接口设计。有时候甚至nosql还是relation db都没得选😂 除非你在infra，cloud相关的team，开发的产品是面向内部的developers，可能会自由选择各种fancy public service & framework。


比如设计一个product catalog service，最关键是这个系统有哪些data，每个object之间什么关系，data relation model搞定了，大致就清楚我需要哪些table，每个table的schema什么样，如何join在一起。接着就需要想这些data如何read/write，那么就是需要什么样的API，每个API的request/response长什么样？定义好这些后，那么就自然进入到系统如何设计这个问题，data processing需不需要offline workflows，为了scaling需不需要拆分service加入message queue。如何handle failures，数据可以暂时存在server local cache里面吗？给client 的response是sync还是async？如何retry等等。


另外在design过程交流很重要，想象一下在现实中要是有个同事的design找你review，但是他自顾自说，你在这方面很有经验但是插不进嘴，是不是很不爽？所以面试要时不时pause一下，问下面试官的feedback。design是tradeoff decision，没有绝对的对与错，所以要明白面试官打断你的时候对方的concern在哪，自己的设计哪些方面没有考虑？


最后，就像实际工作中design doc第一部分是function requirements/non-function requirements，面试中也是需要先把这些写下来。直接就开始画high level design，面试官在这都会扣分。还有就是别花太多时间计算traffic，storage size，除非面试官明确要求你计算，不然可以直接问peak QPS以及数据多大，我见过一些面试者花了不少时间计算，但最后这个计算也并没有为他们的设计服务，就很无用功。。


还想抨击下某些不实用的design题目，比如rate limiter这些就是在考算法具体实现，或者design s3, aws ddb，现实工作这么硬核的design只是少数team在做。。


先说这么多，后续可能会补充把，希望大伙给点米😀

楼主说的很好，sys design是内功，你提问的方式和思考的方式，以及approach问题的方式，非常体现平时的积累和思考过程。很多时候高手过招，只需要点到即可就知对方水平如何。
很多教程会讲的很细，其实是挺好的，但是面试的时候展开讲其实性价比不是很高，例如rate limiter里面的bucket算法有是如何实现的token bucket和其他的区别这些其实不重要，这些算法实际上就是一个参数的区别。
当你还在纠结sql vs no sql的时候，相比楼主问出：“data processing需不需要offline workflows，为了scaling需不需要拆分service加入message queue。如何handle failures，数据可以暂时存在server local cache里面吗？给client 的response是sync还是async？如何retry等等。”
我相信此时高下立判了。

cwyabsolute 发表于 2024-09-13 20:16:17
感慨一下。快2年没有来地里，就想着写个帖子分享下，没想到头几个回复的都在质疑我。你们要是觉得哪个不同意直接说，别傻X地问我拿过几个offer，我要是说靠这个办法

因为你全篇以为的考什么都非常主观却以为自己就是真理，并且前后自相矛盾。开始说设计不考你怎么用就非要考你实现，已经是典型的面试造火箭工作拧螺丝的2b面试思路。自己会原理的就瞧不起别人懂新框架新技术的，后面碰到自己不会的赶紧说object storage会用就行了不用懂设计还喷这么考不合理呵呵。在工作久的人做面试官他可以说object storage就是基础设计你会的s3 GCS就是些fancy技术，在会新技术的人眼里你懂的那些也就是些不需要知道原理的底层东西。谁还没有个自己的出发点，所以前面人说了你是面试官你说什么都对。总结，全篇根本不是个分享只是个充满拉踩的主观说教

楼主说的挺好  但是仅限于API相关的面试题。 可惜的是API的设计最多会出现50%。 比如rate limit 我就被不同的公司面过至少3次。 最牛的一次是把不同公司的实现 进行比较。 而实际工作中在你的api里就是个configuration 或anotation。

所以准备SD 还是要DDIA + Alex xu  and  mocks

你是面试官，你怎么说都对。
要不你把你这套，去拿几个大offer，甩我脸上

为什么不直接用ood coding来考察？

你先上一下市场再叫。

每个面试官想考察的点不一样

你先拿两个offer再叫...

不明白楼上为什么戾气那么重，
我觉得楼主的分享挺好的啊

cwyabsolute 发表于 2024-9-13 20:16
感慨一下。快2年没有来地里，就想着写个帖子分享下，没想到头几个回复的都在质疑我。你们要是觉得哪个不同 ...

哈哈哈哈，我也不太懂喷的点在哪，这一套思路有啥不能拿offer的？？我最近面SD的就是和lz的思路一样，已经拿了一个offer。本来也想写点思路分享，不过lz把我想说的基本上都说了哈哈哈

现在回头看市面上大部分教SD的课程和文章都太浅显，脱离实际，没有提及核心的tradeoff。alex xu的算相对好一点的但有些内容重点也没抓对

谢谢分享
如果工作中，没有机会接触到比较复杂、高并发的系统，业余时间有什么好的办法去学习呢？自己搭一个？我尝试了，但是失败了，因为搭建出来的系统和企业级的比起来还是小巫见大巫。