系统设计集训营简介

全网唯一资深面试官级深度的 32 课时系统设计集训营，覆盖 20 道高频题的精解，深挖以及得分点；解析答题模板，数据流以及面试技巧。用 23 节课帮你快速接近资深面试官的系统设计实力。

集训营适合各个级别的后端及全栈工程师，你将学会的不仅有高频题的正确解法，还有应对各类变体甚至新题的随机应变的能力。

集训营在往期直播课以及爱思官网的十万字的文字版课程基础上进行了大幅内容升级，包括

• 32 课时高浓度干货（7天直播视频回看，2个月录播互动课无限看）
• 20 道系统设计高频题深挖，扩展及得分点
• 千锤百炼的面试答题模板及技巧总结
• 常见设计图组件及概念串讲

爱思作者罗辑授课

硅谷多家顶尖大厂近十年工作经验资深 Tech Lead，作为面试官进行面试近百场，对 Facebook 等大厂面试套路深有体会。作为受试者斩获 FLAGUAP 中绝大多数 offer。拥有多年系统设计面试辅导经验，已经帮助众多学生斩获一线大厂 offer，口碑优异。

授课时间

第六期系统设计集训营将于2022年2月11日开始，持续5周，首节课免费试听，免费试听课将于美西时间  2/11 周五 6:30pm-8:30pm 开讲（美东时间 9:30pm-11:30pm，北京时间周六上午 10:30-12:30)。

每周1节直播课（每节2小时），3-4节录播互动课（每节~1小时）。

直播课每周五美西时间 6:30pm-8:30pm（美东时间 9:30pm-11:30pm，北京时间周六上午 10:30-12:30)。

直播内容将通过 Zoom 在线直播。直播回看提供 7 天内无限视频回看，1年内回看课程课件。录播互动课通过在线平台，2个月无限回看。

金牌答疑服务🏅

直播课进行中，通过 Zoom Chat 提问，罗辑会在每隔一小段时间集中答疑，保证课程节奏同时做到当堂解疑释惑，不让问题过夜。

整个课程期间，一旦有疑问，立刻通过爱思问答询问，罗辑本人作答，保证 24小时内回复。

购买课程

课程原价 $999，限时优惠 $599。购买课程附赠价值 $60 的爱思一年免费会员，畅读文字版课程。购买课程加上老师亲授的一对一系统设计模拟面试服务打包优惠价 $949, 用个性化的指导让你短时间内快速提供。

现在起到 2/10/2022 购买课程的同学，额外附赠价值 $149 的软技能面试速成，帮你轻松应对面试中的软技能问题，薪水谈判不再怕。

欢迎拉小伙伴进入试听群，与拉入群的小伙伴组队报名每人享受 $100 优惠。

接收插班报名，并提供所有往期视频回看。

咨询购买课程请添加罗辑微信，注明 “系统设计集训营”，24小时以内会回复。

课程大纲

第一课【直播】面试官教你如何答好系统设计题 + 即时通讯服务 (Whatsapp)

第二课【录播】设计 Instagram & Twitter

第三课【录播】即时通讯服务 (Facebook Messenger)

第四课【录播】常见系统组件串讲一 - 数据库 & 缓存

第五课【录播】常见系统组件串讲二 - 消息队列 & API 设计 (Websocket, RESTful)

第六课【直播】基于地理位置的系统一 - Uber & Uber Eats

第七课【录播】基于地理位置的系统二 - Yelp

第八课【录播】网络爬虫 (Crawler)

第九课【录播】黑客版爬虫 (Botnet Crawler)

第十课【直播】电影订票系统设计 (Fandango, Atom) + 券商系统 (Robinhood)

第十一课【录播】分布式事务 Distributed Transaction

第十二课【录播】在线文本协作系统 (Google Doc)

第十三课【录播】云存储服务系统 (Dropbox)

第十四课【录播】搜索引擎设计 (Google, Twitter Search)

第十五课【直播】现场学员模拟面试点评

第十六课【录播】系统设计面试技巧与误区

第十七课【录播】在线视频网站设计 (Netflix) + CDN 设计

第十八课【录播】代码竞赛平台 (Leetcode)

第十九课【直播】实时监控系统 (Datadog) + 系统设计 Scalability 总结

第二十课【录播】Trending / TopK 系统设计 (Spotify Top 10 Music)

第二十一课【录播】搜索词条补全系统 (Autocomplete)

第二十二课【录播】分布式缓存设计 (Distributed Cache)

第二十三课【录播】限流器 (Ratelimiter)

Meta, Twitter, Stripe, Salesforce 等等公司接连裁员，科技业人心惶惶。

我会用我经历过的3次裁员中学到的经验，教你看透公司裁员的蛛丝马迹，帮你调整心态面对可能的裁员，带你未雨绸缪快速求职。

罗辑精读 Designing Data Intensive Applications (DDIA)

每周四罗辑带你精读 Design Data Intensive Application 的一章，用十年架构师经验帮你读懂好书。

YouTube

还未买书的同学，欢迎大家通过以下链接购买 DDIA，在支持原作者的同时，支持爱思免费公开课！

购买 DDIA

欢迎同学们将公开课海报分享给有需要的小伙伴，感谢同学们支持本期公开课，我们周四不见不散！

爱思优秀学员 Michael 在过去几个月里拿到5家一线热门公司的 Senior Offer，包括 Google, Linkedin, Tiktok, Doordash 和 Roblox。爱思有幸请他来为大家分享系统准备 Senior 级别面试的心得体会，回顾他从面试前期准备到多家公司临场面试的经历，包含独家的面经分享，大家不要错过！

频道每周末更新，停留鼠标在视频左上角，立刻订阅吧～

李同学在过去的几个月里在职跳槽陆续斩获 FB, Uber, Google, Stripe, Instacart, Doordash 六家公司的Senior Offer。本次免费讲座会回顾他从面试前期准备到多家公司临场面试的经历以及分享他对各家公司面试风格的第一手资料。

欢迎订阅爱思 Youtube 频道，独家内容，定期更新！

此次爱思免费讲座分享了对2022系统设计面试趋势的展望，给同学们高效复习系统设计提出行之有效的建议。吐血总结 Linkedin, Facebook, Google, Amazon, Airbnb, Doordash, Robinhood, Snap, Uber 等大公司新题。

随着世界上的数据越来越多，对于处理数据的需求也日益增加，越来越多的岗位对于SQL有了更多的要求，以至于很多面向数据的岗位都会在面试中对SQL进行考察。SQL的面试可能会让很多未曾接触过编程的人望而却步，而我希望通过这篇文章能够让更多的求职者了解SQL的面试和一些基本的思路。

我在工业界工作多年，一直从事数据库和SQL相关开发工作，想作为相关领域的从业者和面试官来聊一聊我对SQL面试和学习的一些看法和思考，下面会先以一道面试真题来介绍SQL的面试，之后会回答7个常见的SQL问题。

1. SQL面试真题解析

[Social Network] A user(user_id) could write a comment(content_id, type) to a post(target_id) or post(content_id, type) by him/herself. Table schema is shown as below.

Q: What is the comment distribution?

这是一道很典型的SQL面试题目，从这道题出发我们可以总结出很多做题的思路和技巧。

• 首先我们要去理解题目的context。当你对题目所讨论的题目背景不是很熟悉的时候，要多跟面试官讨论。这道题目的背景是social network，用户会post或者对post进行comment，网站记录下来用户的action存入数据库。

• 在此之后我们要了解所提供的table(s)。这里我们只有一个table，但多个table的情况也不少见，这个时候需要注意各个table之间的关系(primary key/foreign key)。在此之后我们可以开始观察每个table里面的columns有什么(甚至需要你知道每个column的data type)，很多时候面试官不会给你具体数据，只会给你提供table schema，就像这道题目一样，这个时候你可以自己添上一些数据作为example，但是一定要仔细思考corner case，即使面试官给你具体数据了，也不要被限制住，很多时候面试官就是想去考察你在写SQL的时候能否把corner case考虑周全。 
• 这道题目只有一个table，table schema也比较直接简单，里面是date: 日期，user_id: 用户的id，content_id: 该用户所发内容的id，content_type: 内容的type，这里是post或者comment，target_id: 如果内容的type是comment，那target_id就是被评论的post，如果type是post，那target_id就是NULL。根据这些信息，在不看问题的情况下，需要注意的可能有以下几点: 关于date的操作，对NULL的处理，一个user可能会对某个post进行多次comment(might be duplicates)。这些都是我在看到这个table的时候一些直觉反应，具体会不会有帮助，我们需要继续去看题目。

• 读懂并正确理解问题。一定要正确理解题意，当你不是很确定的时候，一定要跟面试官确认，有时候题目稍微模糊一点，可能你的理解和面试官想要的就天差地别了。
• 这道题是问comment distribution，就是一个相对模糊的题目了，用中文翻译一下就是评论的分布，但其实它想问的是评论数量的分布，每个post都会有一些评论，题目希望能够把每个post的评论数量统计一下，然后看一下每个评论数量的post都有多少个，例如0条评论的post数量是10个，1条评论的post数量是5个。

• 正确的书写SQL。当你正确理解题目之后，大部分情况下你已经知道这个SQL该如何写了，可以先把框架搭出来，再一点点的去填充，请记住一定不要出现低级错误，一个是因为很容易被发现，另外也很致命。
• 我们这道题已经知道需要一个subquery先group by和count()来得到每一个post的comment的数量，之后再group by和count()上面得到的数量就得到了comment distribution。

• Follow-up questions。现在这个题目还是相对简化的，有的时候面试官会针对这个题目进行一些follow-up，有可能是SQL的延展，也有可能是针对别的知识点的考察。例如：content type拓展，增加like, etc; 题目上面加一些变化，如comment distribution per day; comment distribution会是一个什么distribution(统计相关)，以及为什么。
  

2. SQL面试和学习的常见问题

Q1: 什么样的职位会在面试中遇到SQL题目？

• Short answer: 几乎所有面向数据的职位。
• Long answer: 面向数据的岗位大致有以下几个：business analyst, data analyst, data scientist, data engineer, machine learning engineer。machine learning engineer会考到SQL的概率比较低，但其他的岗位都很有可能会考察SQL，不同的岗位对于SQL掌握程度的要求也会有所不同，甚至涉及的方面也会有一些差异，具体情况需要根据特定公司和岗位的job description再去进一步的分析。例如data analyst的SQL面试可能需要你写出一些SQL query就好了，但是data engineer可能需要你对数据库，table schema design也有所涉足。
  

Q2: SQL的面试考察的内容有哪些？

SQL的面试内容大致分为以下几种：

• 数据库和SQL的基础知识的问答，例如什么是left join，什么是关系型数据库。
• 提供数据信息(table)， 给你一些问题，让你写出一些SQL query，基本以select query为主，很少会去考察你create table这些。这种考察是最为常见的。
• 最后一种我称为SQL case study，基于一个case和面试官交流，可能会经历数据部分的头脑风暴，table schema design，以及根据面试官的一些要求写出一些query。这类考察在很多大公司渐渐推广开来。
  

Q3: 面试中的SQL和工作的SQL有什么区别？

• 面试中的具体场景的context不是很强，更多的是考察你的基本功，或者说做题能力，不会有特别复杂的query让你去写。
• 工作中你可能面对更为庞大的数据，更复杂的schema，例如10+个table的join，和更为严格的要求，例如performance的要求，你的query必须要在多少秒之内返回结果。
• 总结一下，面试中的SQL更侧重你能不能把一个query简洁，快速，bug-free的写出来，而工作中更多的是需要你写出一个能解决问题的query，query要能快速正确的返回结果，同时需要一定的readability。
  

Q4: 如何开始学习SQL？

• 首先，你需要明确你学习SQL的目的，你是希望在工作中有更大的impact，还是你之后的面试会考察SQL，这样你才能更有效率的去学习。
• 如果工作中能够接触到一些面向数据的工具，如Spark, Snowflake，那最好的方式就是learn by doing，甚至可以去看别人怎么使用这些工具，去读别人的代码。其实这就跟学一门外语一样，如果把你放到那个环境中，你自然会成长的更快。当然你也要去学习基本的知识，与此同时，具体生产环境中的案例能帮助你更好的去理解和学习。
• 如果没有这种环境，那我们就需要一些课堂式的学习，例如上课看视频读书，从SQL的基本语法到一些高级用法，一个一个知识点的来学习。辅助以一些练习，例如Leetcode, hackerrank上面的题目。
• SQL的入门不是很难，甚至可以说是相对简单，这也让SQL成为了一个非常popular的语言。但是想要深入学习SQL也不是一件容易的事情，你需要学习更多计算机知识，了解更多的算法细节，对公司的商务逻辑也要有清晰的认识。
  

Q5: 市面上面很多SQL，应该选哪个开始学？

• 首先，如果你知道公司在用的数据库，直接学那个就好了。
• 其次，科技公司最常使用的是MySQL和PostgreSQL，但是MySQL给你提供了很多语法糖，有的时候可能会违背一些你学习的基本知识，有的时候会比较困惑。如果是第一门语言入门的话，我比较推荐PostgreSQL。但是如果你想去面试一些传统行业的公司，很有可能他们有一套Microsoft stack，所以SQL Server应该是你的首选。
• 最后，其实精通一个SQL就好，基本语法都差不多，可能在处理timestamp和null value的时候会有一些区别，除此之外，更多的区别基本上是感受不到的。而且你精通了一门以后，即使有区别，你也会很快的catch up，都是殊途同归的。

Q6: 需要掌握哪些SQL知识?

[基础]：

• Basic syntax: SELECT, FROM, WHERE, HAVING, GROUP BY, ORDER BY, etc.
• Aggregation: SUM(), MAX(), MIN(), AVG(), etc.
• JOIN: Inner/Left/Right/Outer/Cross
• Subquery, CTE
• Query Execution Order

[进阶]：

• Window Function
• CASE WHEN
• NULL value
• TIMESTAMP

上面的这些内容基本上涵盖了面试中95%的知识点，当然还有很多其他内容在这面没有提及，例如query plan，query optimization，database schema design，primary/foreign key, etc.

Q7: 如何在SQL和职业上进阶？

• 有的时候我们会听到这么个词，叫做SQL boy，有些人会解读成为写SQL的流水线工人，写着写着SQL就只写SQL了，每天就是跑跑写好的SQL，看看结果，report一下，职业发展看不到什么希望，这其实是很多从业者的担忧和困惑。在我看来，SQL boy也不是那么好当的，我们很多时候对于SQL query的要求很高，如果你写的query质量不达标，十分影响整个团队的工作进程，所以如果你觉得没有希望了，可能不是SQL boy的问题，更多的是你需要换公司或者team了。
• 关于职业的进阶，除了能把SQL写好以外，你更需要考虑的是个人的职业规划，你希望未来向什么方向发展，是更偏product和bussiness，还是去做data scientist，还是说在数据和SQL处理这部分更进一步去做data engineer，这个可能是更重要的事情，因为你除了SQL还需要学习更多其他的技能才能让你走的更远。

本次免费讲座，我们将分享爱思系统设计课第三期优秀学员 Adrian 的成功求职经验。Adrian 同学在过去的几个月里在职跳槽陆续斩获 FB, Uber, Linkedin, Doordash 四家大厂的Senior Offer。本次讲座会回顾他从面试前期准备到多家公司临场面试的经历以及分享他独到的学习心得和方法论。

这是一道老题了，也是一道高频题，今天就用这道题来给资深面试官眼中的系统设计一文中答题流程做一个实例。

资深面试官眼中的系统设计

如果你对系统设计面试还有一知半解，这篇已经帮助过8000名同学的教程一定能帮你答疑解惑。我们这就来聊聊为什么要考系统设计，具体考什么，以及如何作答。

爱思系统设计罗辑

如果你想跟罗辑一起更深入地学习系统设计，有兴趣的同学报名参加爱思备受好评的系统设计集训营以及系统设计模拟面试服务，由作者本人为同学们教学，力求给大家带来最深入的系统设计高频题讲解以及最针对面试实战的技巧解析，帮助同学们举一反三，高效准备面试。

爱思系统设计集训营「免费试听」

全网唯一资深面试官级深度的系统设计集训营免费试听课将于美西时间 4/22/2022 6:30pm 开讲。试听课覆盖系统设计考察要点，答题模板以及 Whatsapp 精解。完整课程共32课时，旨在培养扎实的系统设计能力。深挖20道常见系统设计面试原题，提炼面试答题技巧，详解设计图组件，总结分布式系统知识。有效帮你融会贯通，增加你的答题深度广度，让你能够举一反三，从容面对面试官的追问以及新题。

爱思系统设计罗辑

爱思系统设计模拟面试服务

爱思创始人罗辑拥有近十年硅谷面试官经验，作为面试官，参加真实面试以及模拟面试分别超过 100 场，为你带来最真实的系统设计模拟面试。好评率 100%，专业帮同学们准备一线大厂面试，已经帮助大量同学拿到大厂 Offer。$399，赠送本站一年会员，价值 $59.99，畅读独家题解，等你来约！

爱思系统设计罗辑

同学们不要死记硬背答案，而是体会一下一步步破题的过程。因为面试流程不唯一，真正碰到这道题的时候面试官的 follow-up 会不一样，大家还是要注重积累，本文试图尽量触及足够的广度，但也无法保证面面俱到。

先扩展一下这道题，这本质是道 New Feed 题，Design Facebook, Design Instagram, Design Twitter 都是一回事，不要被马甲迷惑。

想要直接看答案总结的可以跳到本文末尾，有完整的系统设计图。

那现在我们这就开始按照资深面试官眼中的系统设计中的流程来答题。

1. 理解需求 - Requirement Exploration

下面是一段虚拟的对话。

Interviewer: Today we are going to have a system design interview. Our goal is to design Instagram. You don’t have to cover everything. We can drill into specific topic when we get there. Are you familiar with Instagram?

Interviewee: Ya, I use it all the time. It’s photo sharing app. Before we start, can we take a step back? What’s the purpose of this “Instagram” we are building? Are we trying to compete with the real thing?

Interviewer: Let’s imagine that Instagram doesn’t exist yet and people don’t have a good app to share photos broadly.

Interviewee: Good to know. What features do we want to cover? I think we have two basic features - upload a photo, get a feed from followers and follow/unfollow . Sounds good?

Interviewer: Cool, that’s a good list. Let’s focus on the first two for the sake of time.

Interviewee: How about latency? I think this would be an important requirement too. I assume we want to have minimal latency - probably less than 0.5 second for loading feed.

Interviewer: That’s a good call out.

Interviewee: OK. (write on whiteboard). So functional requirement is to support 1) uploading photo and 2) retrieve feed from followers. Non-functional requirement is 1) Feed retrieve latency of less than half a second, 2) highly available. 3) highly reliable (data never lost). Non-requirement is follow & unfollow.

Interviewer: Makes sense.

Interviewee: Do we need to consider feed ranking?

Interviewer: Let's skip that for simplicity sake. Let's assume feed is ranked in reverse chronological order. Basically latest photo on top.

Interviewee: Sounds good.

从这段对话里受试者进行了以下三步。

• 询问系统的商业目的 - 在没有 Instagram 的世界里重新造一个，让大家可以分享照片。
• 询问功能性需求 - 能上传能看 News feed, 新照片排前面，用户体验要流畅。
• 询问非功能性需求 - Feed Latency <0.5 s, Highly available, Highly reliable

2. 资源估算 - Back of the Envelope Calculation

说到这里，我们粗浅地了解了一下需求，还没有对 non-functional requirement 进行量化和细化，这就需要我们进一步做资源估算。

继续我们虚拟的对话。

Interviewee: I assume there are a lot of people want to use this service. Shall we assume the scale of the service is similar to the real one?

Interviewer: Yes. Let’s assume daily active user is 800M.

Interviewee: How often do people upload?

Interviewer: Let’s assume people post every 10 days.

Interviewee: Assuming daily active user makes 10 requests a day and post every 10 days. I think we can calculate the read/write QPS. (Write on whiteboard) I think read QPS is 800 * 1000 * 1000 * 10 / (3600 * 24), roughly 90k QPS and write QPS is 1/100th of that which is 900 QPS. Don’t think this will fit on one machine. (Laugh)

Interviewer: No, it won’t.

Interviewee: We will need a lot of storage here. Majority would be to store photos. Assuming we store all photos for 5 years and a photo is 1M, we will need 800 * 1000 * 1000 * 365 * 5 * 1M / 10 = 146000 TB = 146 PB. It will take one or multiple data centers to hold.

Interviewer: Sounds good. Let’s proceed with a high level design.

我们进一步地对非功能性需求进行量化和细化。

• Feed Latency <0.5s
• Support 800M DAU
• Highly available (while supporting read 90k QPS, write 900 QPS)
• Highly reliable (while storing ~146PB data)

提示两点。

• 注意整个过程中受试者在主导这个需求探索的过程，面试官对受试者给出的需求和数字做确认并少量给出受试者不知道的关键信息（比如 DAU 800M)。不要让面试官做过多的单方面灌输信息。
• 关于数字的计算少数情况下因为时间关系，面试官会让你跳过。如果算得不利索的话，建议跟面试官确认一下。相信这个小学数学对大家都不难，我的小技巧是365*24就算作10000就好，数量级对就行。

3. High-level Diagram

了解需求之后，我们可以开始画一个简单的图来说明我们的核心服务是如何构建的。

在上图中，我们并没有过多考虑 Scalability，而是提出一个小流量下可行的方案。在画图过程中，我们需要考虑的核心问题是 Push vs Pull. 上图中提出的是 Push 的方案。我们一边画图，一边就可以跟面试官提出这个 Trade-off. 我们提出我们意识到这是一个 Read-heavy application.

• Push 好处是 Latency 低，符合之前定义的 Latency < 0.5s 的要求。
• Push 坏处是 Fanout 过程中耗时更长（因为一个人可以被很多人 follow，比如celebrity)，能保证数据的 eventual consistency，但不能保证最新照片及时进Feed. 当然这里可以提专门为 celebrity 的优化， 后面核心子服务会提到。

可以跟面试官确认 Push 的缺点是不是可以接受。

4. 数据结构与存储

4.1 数据库的设计

以下设计偏向于非纯 key-value store 的存储方案。如果想选用 key-value store，如Redis, 以下表的设计可以酌情做一些调整。

• Post Table (post id as sharding key)

• User Table (user id as sharding key)

• Feed Table (user id as sharding key, create time as secondary index)

1) 这里 create time 是必须的，在返回 Feed 过程中我们需要按照这个排序。因为我们用了 async worker 来写 feed table, 我们无法保证先写进来的一定就是create time 更早的照片。2) 选用 user id 做 sharding key，使用 create time 来做 secondary index.  3) 使用 author name & photo URL 而不是 author id & photo id 避免了与其他表在读取时进行 JOIN。

• Follow Table

或

这边要说明 Trade off：

Push 方案里我们总是拿 user id 去找他被谁 follow 了，而 pull方案里我们总是拿 user id 去找他 follow 了谁。当然我们也可以两种都存来做一个 hybrid approach，下面会提到。

4.2 存储系统

缓存, 数据库和对象存储分别用什么？

4.2.1 缓存 (Cache)

• 数据库的缓存 - Redis, Memcached 我们可以在 Feed Table 之前加一个缓存，在每一次有 Feed 用户请求的时候，可以预加载比 Feed 请求多几倍的数据，这样在用户请求下一页或几页的时候直接从缓存中读取。这个缓存可以使用 LRU 作为 eviction policy。
• 文件系统的缓存 - CDN. 想象一个有很多粉丝的明星发的照片会被很多人看到，我们是不是需要每一次都从文件系统里拿呢？显然不行。对于大文件的缓存我们需要把文件提前部署到世界各地的 CDN 上，这样需要访问时就能第一时间从最近的 CDN 拿到数据。

4.2.2 数据库 (Database)

Cassandra, MySQL ... SQL vs NoSQL? 在这道题上是个仁者见仁，智者见智的问题。我们至少要意识到这是 read-heavy application。SQL 这边有 MySQL ，做 key-value store 性能也不错，NoSQL 有 Cassandra, read-heavy, write heavy 都可以，保证eventual consistency.

4.2.3 对象存储 (Object Storage)

Amazon S3 是可以考虑的分布式对象存储。

5. 核心子服务设计

我们来细化 Feed Service 的架构。

前面我们发现了 Push 带来的 Celebrity Fan-out 的问题。我们就在这个阶段提出 Hybrid approach . 简单来说，我们用一张新的 post table 去专门存超过一定 Follower 数量的 celebrity post，然后每次取 Feed 就直接从这张比较小的表里去找 celebrity 的 post，然后与 Feed table 合并排序。上述的方案会让我们的系统中包含两个 Post table，一个是 celebrity post，另一个是 non-celebrity post。一种更简化的方案是仍将所有的 Post 合并到一张Post table，但使用一个新的列，is_celebrity_post 来加以区分，在分片时，我们可以用这一列作为分片的依据之一。

注意这边 celebrity post 我们就不写到 Feed table 里了，顺便解决了每次 celebrity post 时，async worker 的负载大大增加的问题，使其更稳定。

这里值得讨论一个细节，我们能不能定一个 Follower 数量的限制，这样是不是就不用专门用一张新的 post table 去存了呢？其实不然，因为用户的 Follower 数量是会波动的，如果用户正好在那条线上，会造成 fan-out 时有时无的情况。当然，我们建了新的 celebrity post table 也会带来问题，就是如果有了新人一下子变很火，我们怎么把他们加入这个我们认定的 celebrity 的行列。方法很简单，其中一种是从普通的 post table 去 backfill celebrity post table，另一边从 Feed table 里去除他们的 post.

6. 接口设计

GET /v1/feed?count={count}&last_timestamp={timestamp}

现在我们思考一下 Feed API 这边写的 count 和 last timestamp 是什么用意呢？

答案是分页 (Pagination)。每一次 getFeed，我们不可能把所有的该用户的 Feed 一股脑的发回去，我们必须分成一段一段地发。那么问题来了，怎么才能取回第二页呢？

最直接的想法是在 getFeed 中发一个 page id 和 page count，告诉服务器我想从第几页开始取，每页是几张照片。这个做法是不对的，因为用户的 Feed 是会增长的，如果取第一页和第二页之间有了新的 post, 那返回的图片的 index 就会错位。

正确做法是传 last timestamp 和 page count，这样就解决了错位的问题。

POST /v1/images

以上 API 用于把图片本身上传到服务器端，换取一个 URL，S3 提供类似的功能。

POST /v1/posts
{
    "image_url": image_url,
    "description": "hello world"
}

以上 API 用于把 Post 上传到服务器端，包括图片链接以及文字介绍。将图片本身的上传和 Post 的上传分开允许我们在产品逻辑里将两者的发送时间分开（照片可以在文字介绍还没编写好之前就上传），另一方面允许我们更好地复用服务，特别是前者，图片上传服务可以被很多别的 API 利用。

这里没有将 User ID 放在 API 的输入当中是考虑我们不会去以他人名义发送照片或者取得他人的信息流，所以两个 API 可以默认用户是当前被 Authenticated 的用户，实现上可以从 Auth Token 里拿，而不必从 API 中拿。

7. 扩展性，容错性，延迟要求

我们来进一步按照以上四点来进一步优化我们的设计以满足我们在第一节中收集的需求 - Low Latency, High Reliability 和 High Availability.

7.1 扩展性 (Scalability)

Scalability 讨论在数据量和访问量增大的情况下，我们如何应对。这里我们梳理一下之前为了 Scalability 所作的选择。

• High-level diagram 中的 Load Balancer
• 存储系统里的缓存，数据库和文件系统
• 核心子服务 Feed Service 设计中的 Hybrid approach
• 接口设计中的分页 (Pagination)

以上这些设计让我们可以通过加机器的方法来应对与日俱增的数据量和访问量。

7.2 容错性 (Fault-tolerance)

要构建一个在服务器众多的服务，我们难免会碰到硬件和软件的不稳定性。面对这些难以预测的问题，我们怎么才能让用户感受到一致并且理想的体验呢？那就是提高容错性。

提高容错性的目标是两点。

• 无单点故障 (No single point of failure)
• Fail gracefully

我们在这题的情景下分别检视每个系统组件，看看如何达到以上目标。

• Post Service 和 Feed Service 需要有多台服务器由 Load Balancer 去分配请求，当某台机器出现有问题的时候，请求会被发送到别的机器上，造成服务的延迟增加而不是无服务的状态。
• 缓存需要有多台服务器，如果一台出现问题，其他的缓存仍能正常工作，使得这样数据库访问有限地增加。问题缓存重启后，我们失去了该缓存的数据，只能慢慢恢复，然而一段时间后数据库访问会回到原来状态。
• 数据库和文件系统需要有备份，我们是无法容忍数据丢失的。常见的方法有Master-slave replication, Master 承担“写”请求，Slave 承担“读”请求，Master 的数据在满足 eventual consistency 的条件下备份到 Slave上。Master如果出现问题，一台 Slave 会被 promote 成 Master。Slave 因为有多台并且承担一样的任务，其中一台重启的时候，Master 只需给它补上丢失的数据即可。这样不仅备份了数据，而且降低了每台机器接受请求的压力。

7.3 延迟要求 (Latency)

在前面的第三小节 High-level Diagram 中，我们在讨论push vs pull的时候选择push的核心论点是这个服务是 read-heavy 并且延迟必须足够低。在此后采取 hybrid approach 的优化后，系统延迟仍会低于 pull。

8. 监控和警报

监控核心指标并设立警报。实际系统里的指标远不止以下，这里举一些重要的。

• 服务QPS
• 服务延迟
• 服务可用性 (Availability)
• Async worker load
• 系统缓存命中率
• CDN 缓存命中率
• 数据库使用比例
• 文件系统使用比例

9. 专题 deep dive

9.1 数据分片 (Sharding)

这道题面试官可以找到很多角度去深挖，这里就提一个比较常见的考点。问题是这样的 - Instagram 的 Feed Table 数据量单机无法承受的时候，你会怎样 Scale up?

最直接的想法是，对于每个 user id 做 hashing，分别放在不同的机器上。这样说答对了一半，面试官会跟进，问这样会不会造成有的机器很满，有的很空，如果某些机器又满了怎么办？

要解决这个问题的机制比较复杂，Cassandra 的设计给我们提供了很好的设计思路，我们可以使用 Consistent Hashing 的 Hash Ring 来解决 node re-distribution 的问题。

10. 总结

在面试的过程中，我们一边思考，一边改进我们的系统。最终的系统大概是这样的。

我们回顾一下最初写下的需求，看一下是不是都满足了。最后再跟面试官确认一次。

系统设计是为了满足特定需求，定义计算机系统内构架，模块，接口和数据的过程。这是每一个后端或者全栈工程师的必修课，随着工作年限的增长和项目的扩大，系统设计在日常工作的重要性会不断增加。

如果你想跟罗辑一起更深入地学习系统设计，有兴趣的同学报名参加爱思备受好评的系统设计集训营以及系统设计模拟面试，由作者本人为同学们教学，力求给大家带来最深入的系统设计高频题讲解以及最针对面试实战的技巧解析，帮助同学们举一反三，高效准备面试。

爱思系统设计集训营「免费试听」

全网唯一资深面试官级深度的系统设计集训营免费试听课将于美西时间 4/22/2022 6:30pm 开讲。试听课覆盖系统设计考察要点，答题模板以及 Whatsapp 精解。完整课程共32课时，旨在培养扎实的系统设计能力。深挖20道常见系统设计面试原题，提炼面试答题技巧，详解设计图组件，总结分布式系统知识。有效帮你融会贯通，增加你的答题深度广度，让你能够举一反三，从容面对面试官的追问以及新题。

爱思系统设计罗辑

爱思系统设计模拟面试服务

爱思创始人罗辑拥有近十年硅谷面试官经验，作为面试官，参加真实面试以及模拟面试分别超过 100 场，为你带来最真实的系统设计模拟面试。好评率 100%，专业帮同学们准备一线大厂面试，已经帮助大量同学拿到大厂 Offer。$399，赠送本站一年会员，价值 $59.99，畅读独家题解，等你来约！

爱思系统设计罗辑

1. 为什么要考系统设计面试？

实际意义大

跟算法面试类似的，面试官需要能从人群里分辨出谁更适合所招聘的职位。系统设计作为日常工作中会经常用到的能力，在考察中有很强的现实意义。可以想象，如果一个组里需要找资深工程师来帮助升级服务的构架，系统设计能力会决定岗位的归属。

区分度高

系统设计面试可以看出受试人对问题多方面的理解，不同水平的受试人对于问题的广度和深度会有很大差异，很大程度上帮助面试官了解受试人的能力以及确定未来职位的级别。

2. 系统设计考什么？

• 交流沟通和理解能力 - 跟面试官充分交流理解所设计系统的目标，方便做设计中的tradeoff，在厂里干过的就知道日常工作中这个非常重要
• 设计和架构能力 - 很多我见过的面试者都只注重在这块而忽略了其他，很可惜
• 扩展性 (Scalability)，容错性，延迟要求 - 跟Operation相关的要求，如今Dev和Ops不分家，希望面试者了解系统今后能如何扩展，易于maintain
• 资源需求 - 对于我们所要求的QPS和latency，需要多少台机器，其中CPU, 内存，硬盘等资源都是如何配置

当然，以上四点，根据同学们的实际情况，并不用在每一点上都给出完整的回答，面试官会在面试过程中指出深挖的方向，有可能是根据同学的专业或者职业背景，有可能是根据所面试的岗位，有可能是根据面试中同学提到的他熟悉的技术。

3. 怎样答好系统设计题？

在面试生涯中，见过的最优秀的面试者比我的级别要高，让我印象非常深刻，四个字，深不见底。

面试的前半段，面试官会先从广度下手，要求受试者对题目的大框架给出一个完整的正确的解法。如果受试者给出了足够好的解法，那么面试官会从受试者的提过的某一个细部进行深挖，可能是深挖scalability，可能是改变一个需求要求重新做tradeoff，可能是某一个service的细节设计。因为其中的细节足够多，受试者一般很难准备得面面俱到，面试官可以比较清楚的画出受试者的能力边界。前面提到的这个受试者之所以让我感到深不见底，是因为我才疏学浅，画不出他的能力边界，不得不赞叹大神，在debrief中好好膜拜了一番。 说了这么多，还是想说平时的积累很重要，面试速成能够让你在广度上做的很好，深度方面还是要多花时间学习。

讲完了废话，讲一些可以操作性强的，我们结合考察内容，对优秀回答的特征做进一步表述。

交流沟通和理解能力

• 询问系统的商业目的 - 建这个系统是为了解决什么问题。相关的问题比如这个服务的受众有什么特点，是商业用户还是个人用户。很多时候问不问这个问题就能看出Senior的程度。
• 询问功能性需求 (functional requirement) - 包含哪些子功能。
• 确定非功能性需求 (non-functional requirement) - 我们要总结说我们在面试结束前我们的设计要达到什么QPS，latency或者availability指标。写下来并跟面试官确认。如果这里牵涉到一些ballpark calculation，跟面试官确认是不是需要算。
• 整场面试过程中跟着面试官的引导走- 有的同学看到准备过的题就很兴奋，文思泉涌面试官都拉不住，会让人觉得理解能力不足

设计和架构能力

这是正常面试的核心部分，非常重要，是面试通过的基础，其中deep dive非常考验真实水平。讨论过程中记住要保证设计的完整性，正确性以及取舍的充分沟通。答题点主要分成以下五大块。

• High-level diagram
• 数据结构与存储
• 核心子服务设计
• 接口设计
• 专题 deep dive

扩展性，容错性，延迟要求

• 确认系统在以上三点 Scalability, Fault Tolerance, Latency Requirement是否符合先前定下的需求。
• 根据需求进行改进（推荐在第一轮设计中先不考虑这里的三点，先拿下设计和架构能力的分数，再做改进）
• Log，monitor and alert on key metric (系统投入使用前，把非功能性需求和它的leading indicator确定下来并且做好监控）

资源估算（optional）

估算非功能性需求，计算需要多少台机器，需要多少内存，硬盘，带宽和CPU的能力，量级正确即可（back of envelope calculation)。

5. 答题流程 + 时间分配

面试中常见的错误是答题流程松散，在不必要的话题上浪费时间。我见过不计其数的受试者纠结于一个特定话题导致没有时间完成面试的主体部分。我们来看看怎么避免这类错误。

形成固定的答题流程的作用有二。一是引导面试官进入你的答题框架，二是用固定的流程保证不漏过重要的得分点。

引导面试官

虽然面试官在系统设计面试中有比算法面试更强的引导的责任，但是引导的行为只有在需要的时候才会发生。如果一场面试中，总是受试者提问，面试官回答，受试者滔滔不绝地讲，面试官连连点头，画面是不是很美？虽说前面的情景很理想化，但是如果我们能很好地把面试官想踩到的点按一个大概的顺序去踩到，不仅面试官会更少地打断受试者的思维，而且面试官也会在面试中很省力给你个好印象。当然，如果引导发生了，那么一定要根据引导来思维。

答题流程

以40分钟的面试时间来算（掐头去尾除去自我介绍问问题），我面试的大概流程如下。

• 【3分钟】理解需求 （询问系统的商业目的 + 询问系统的功能和技术需求 + 定义成功）
• 【0-5分钟】资源估算（optional)（计算需要多少台机器，需要多少内存硬盘和CPU的能力）
• 【5分钟】High-level diagram
• 【5分钟】数据结构与存储
• 【10分钟】核心子服务设计
• 【5分钟】接口设计
• 【5分钟】扩展性，容错性，延迟要求
• 【2-7分钟】专题 deep dive

注意几点，4，5，6顺序没太大关系。8可以考虑成额外分数，答对大量加分，答错少量减分，如果没时间会跳过，也是少量减分。

看完这个流程是不是感觉分秒必争，要踩的点很多，没有时间浪费。这时候如果面试官听出来某一步骤有错误，就算是回头改对了，浪费的时间也会造成一些本能踩到的点因为时间不足踩不到，所以大家还是好好准备，刷算法题之余也把系统设计重视起来。

爱思作者罗辑 亲自教学

硅谷多家顶尖大厂近十年工作经验资深 Tech Lead，作为面试官进行面试近百场，对Facebook 等大厂面试套路深有体会。作为受试者斩获 FLAGUAP 中绝大多数 offer。拥有丰富模拟面试辅导经验，帮助众多学生斩获一线大厂 offer，口碑优异。

$399 1.5小时模拟面试

1小时系统设计模拟面试（英语）+ 30分钟深度反馈（中英可选）+ 反馈报告 + 微信答疑。 罗辑亲自教学，无外包，资历和教学质量远超同类服务。Zoom 远程音频，无地域限制。模拟面试结合本站资料复习，助你临门一脚，offer 连连！

赠送一年会员 畅读独家题解

想要更加高效准备又不知道该如何下手？从模拟面试中发现了不足却不知道该如何提高? 爱思为所有模拟面试用户赠送价值 $59.99 的一年网站会员，包含独家题解及配套资料，帮你事半功倍，经验值蹭蹭涨！

模拟面试预约

付费方式

扫描微信二维码咨询

扫描二维码添加罗辑好友，注明“模拟面试咨询”。罗辑会帮助解答你的疑惑。一天之内回复。如急需模拟面试，请通过上方预约工具预约，锁定你的时间。咨询亦可发送邮件到 acecodeinterview@gmail.com。

学生口碑

陈同学（横扫 Facebook, Lyft, Amazon, Databrick Offer)

“给你说声多谢！你的模拟面试很有帮助。让我避免通过正式面试来交学费。这次注意了掌控时间，发挥得更好。后面我的面试全都过了，觉得钱花得很值！”

赵同学（横扫 Facebook, Google, Waymo offer)

“特别特别谢谢您的 mock interview，收获巨大无比，我觉得算是点醒了我，让我知道系统设计面试大概怎么回事儿，应该怎么准备和回答。之后所有面试都过了，真的太感谢您啦！”

王同学（斩获北美字节跳动 Offer）

“谢谢您的系统设计培训，并且发在网上的文章写得特别不错，是那种从零到一，启发式的文章。特别谢谢您，对这次跳槽特别的满意。”

超高性价比