Add icon
Add cover
Add comment
我的系统设计准备心得
从9月中开始到10月中，准备了三周的系统设计，最后很幸运拿到了offer。现在分享给大家希望能帮助你拿到心仪公司的offer！
系统设计面试准备有什么好材料推荐吗？
我只是路过（还没有面试）：推荐关注Alex Xu的小红书账号！一张图给你很清晰地讲清楚系统结构。可以平时当作了解自己的业务，在真正面试来临的时候有更好大局观！同时也可以看一个demo录像Amazon System Design Interview: Design Parking Garage熟悉一下系统设计的面试
我有面试了（准备期）：推荐Hellointerview和TechPrep，有余力再看ByteByteGo
我要面试了（冲刺期）：自己建立的系统设计小抄（下面有我的版本）
系统设计面试是怎么样的？
一个基本的系统设计面试基本分为以下7个步骤：
Functional Requirement 聊聊系统的基本功能实现，例如：能增删改查，能实时对话，能图片共享，是离线通知…
Non-Functional Requirement 聊聊系统的“伤疤” SCAR (scalability可扩展性， consistency数据一致性，availability可用性，reliablity可靠性）
Estimate聊聊数字（三个数字，DAU日活用户，QPS每秒数据库交互次数，Read-Write Ratio读写比）
Api Design聊聊端口的设计（endpoint, input, output）
Data Model聊聊数据库表设计
High-level Design聊聊高阶系统设计
Dive Deep 深入聊聊技术细节
上述的步骤重要性并不是均等的：
Functional Requirement(1)是所有的基础，会引申出对non-functional(2)的思考；
而为了实现non-functional(2)我们需要计算数字estimate(3)；
基于要实现的Functional Requirement(1)，我们需要进行API design(4)；
谈到了API design(4)的输入输出，我们需要设计Data Model(5)；
所有都设计好的时候，我们就可以回到每一个要实现的功能，顺着flow，描绘出整个High-level Design(6)。
到此为止已经完全设计好了，但是为了优化non-functional(2)我们需要在整个High-level Design(6)找出可以优化的两三点进行Dive Deep(7)
如果理解了上述步骤的重要性，你会发现：大家普遍被System Design吓到了，因为听说需要考察算法，深入探讨，技术细节…
但实际上，如果你不是senior或者staff，普通sde2的系统设计重心都是只是在前面六个步骤.。好像数学考试，尽管不熟悉最后的一道大题，前面做好也可以很高分。
所以不要自己吓自己！
要怎么从零开始准备系统设计面试
系统设计就像是建房子。你问我怎么从零开始建房子，那肯定先把大问题拆分为小问题。
怎么从零开始建房子？—>怎么从零开始建房间？—>一个房间里都有什么？
所以，现在，我先帮你把你要看的材料/房间内部分类一下：
一致性哈希（Consistent hashing)
键值对储存（key-value pair）
全局唯一UUID
分片计数器（Sharded counters）
速率限制器（rate limiter)
滑动窗口、令牌桶算法（sliding window, token bucket)
blob存储（blob storage）
消息队列（message queue, kafka）
双向通信技术(polling, long-polling, web socket, SSE)
反向索引（reverted indexing）
地理哈希（geohash, quadtree)
一致性算法（Consensus Algorithm: Raft）
Fan out
网关（gateway）
负载均衡（load balancer）
通知系统Notification System
双向通信系统
Feed publishing
Graph DB
Concurrent Lock & TTL
replicas
elastic partitioning
Elasticsearch
Kafka
streaming
YouTube
WhatsApp
Twitter
Instagram
Amazon
Google Drive
Tinder
Airbnb
Uber
PayPal
Spotify
TikTok
Netflix
机智的你应该能看出来，从左到右三列分别是系统设计的微观，中观，和宏观组件或系统。
最左一列是最底层你要会但是也最唬人的算法或组件，要是问起这个组件的底层原理，不是大牛的话谁都会害怕。
中间一列是你经常会在系统设计面试中提起的组件或机制，要是你提及到了正确的组件，面试也就稳了。
最右一列是你经常会在系统设计面试中见到的题目类型，准备好这几个经典类型，其他都是举一反三。
我会建议从右往左的方向来准备系统设计。
准备1：先从经典的系统视频讲解开始
我的做法是从经典系统的视频讲解开始。
看TechPrep或HelloInterview，找到自己感兴趣的案例视频讲解。
看的时候，使用Template做笔记截图。
觉得说得好的地方，把原话记下来！（这很重要，待会说）
这里一般我选择精看Functional, non-functional, API, High-level；
Dive deep先截图以后再看
归纳出这个系统的重要组件
重复第1步，看够8-10个左右视频，直至你感到其实系统架构大同小异，于是你想归纳出一些面试中提起的组件或机制
准备2：看完视频之后一定要做的事
归纳这么多视频下来，自己发现的常见的组件。例如说：
甚至你可以套娃：
看到这里相信你一定会觉得系统设计就像呼吸一样简单。
但是，还不够！我要说很多人都不会注意的点：表达！
因为本质上这就是一场面试，面试的核心不是presentation而是communication！所以一定要会表达。但如果你参与的是英文系统设计，有时候表达会成为思考的阻碍。于是我们就需要，把视频里native speaker的表达再拿出来！例如，以下是我在看视频时，觉得non-functional requirement说得很好的justification：
high availability
for each request, ensure users can access the platform without interruptions, even during the peak time
eventual consistency
since the nature of data is not very important unlike financial applications
high consistency
since this is transaction related, so we would expect high consistency
high scalability
we want this to be able to handle not only millions of attractions but also to be able to handle millions of user query simultaneously
low latency
when they raise a request, they get a response very quickly without having to wait for a long period of time. Ensuring smooth and responsive with minimal delay to maintain an engaging experience
例如：我看到API设计的时候，简单提一下为什么不用GraphQL：
Why restful API over GraphQL, SOAP, gPRC?
REST APIs：
simple and well-established, using distinct endpoints for each resource, which makes them easy to implement and REST benefits from strong HTTP standardization and widespread tool support
can lead to over-fetching or under-fetching of data.
GraphQL:
allows clients to request exactly the data they need in a single query, reducing the number of API calls, excels in scenarios with complex data relationships and evolving requirements
introducing more complexity in both implementation and query structure
GraphQL offers more flexibility but requires advanced caching strategies since it doesn't use HTTP methods like REST
Feature of Restful API
Simple, classic, stateless, support caching
For good Restful API security, always mention JWT
put userId in jwt token header for security
例如：我看到High-level Design的时候别人一句话带来网关和负载均衡：
This should be the first component or service where our client requests land on and I would like to implement features here like:
Rate limiting
Routing
Auth & Authz
—--------------------------------------
Additional auxiliary services like: SSL termination
准备3：有余力再去研究深入的算法和技术细节
这是最后的一个mindset，提醒自己不必凡事尽善尽美才出发，这样有时候无形给自己太多压力。
有空的时候我再去思考为什么一致性哈希要这样设计，无聊的时候我再去想UUID的雪花算法究竟是什么，等我开心的时候，再看看令牌桶算法怎么看上去这么简单。