英文原文链接：https://www.hiredintech.com/classrooms/system-design/lesson/55
从这一节开始，开始介绍当拿到一个System Design问题时候应该如何处理。
-----------------------------分隔符------------------------------------------------------------------------------------
系统设计过程：
- Step 1 约束和用例
- Step 2 抽象设计
- Step 3 理解瓶颈
- Step 4 可扩展性设计
Step 1 约束和用例
和算法设计相同，系统设计问题同样也没有得到全面而明确的定义。考虑一下上一篇文章中提到的URL缩短服务（设计一个类似“bit.ly”的URL缩短服务），对于这个问题其实有许多不明确的地方。再没有了解清楚的情况下，设计出一个恰当的解决方案是几乎不可能的事情。
在拿到一个问题的时候，第一件事情是要明确系统的约束和系统需要满足哪些用例。通常，在面试中，每部分面试官想考察的是你能否立刻获取这个问题的需求，同时设计一个能够覆盖满足这些需求的解决方案。永远不要期待能够在一个问题没有清楚地被表述的时候能够解决它！
举个例子来说，URL缩短服务可能受众只有几千的用户，但每个用户可能会共享数百万个URL。它可能需要处理短URL上数以百万的点击，也有可能点击量只有几十。这个服务可能需要对每个短URL提供扩展性的统计（这会增加数据存储量），当然也有可能没必要提供这个功能。
下面以URL缩短服务为例子，分析约束和用例：
用例（系统需要完成的功能）：
- 缩短URL：将一个长URL转换为一个短URL
- 重定向：接收到一个短URL后，重定向到长URL，即定向到真实地址
- 自定义URL功能
- 统计分析功能
- 链接自动过期（为短URL设置expiration time）
- 手动删除链接
- UI或者API（这个service是一个有界面UI可供直接操作的web service或者website还是提供API供其他服务调用）
在实际场景下，可能并不是上面都需要实现。在我们后文的讨论中，暂时不考虑后面斜体的功能部分。
约束（性能指标）：（do some math！）
- 每月新增URL：100million
- 每月request数：1billion（每个URL的生命周期为1-2周，在此假设为平均值~10天。假设点击数为1次/天，所以100million × 10days × 1 click/day = 1billion/month）
下图是估算这个值的方法，可以参考一下： 
- 10%的流量流向缩短URL服务，90%流量流向重定向
- 每秒request数：400+（40：缩短；360：重定向）
- 5年内6billion urls
- 每个URL大小为500字节
- 每个URL的hash值为6字节
- 五年时间，url总大小为3TB，hash总大小为36GB
- 每秒写入的新数据约为20KB
上面的数据实际上都是估算的，为了能够得到尽可能准确的估算，实际上是需要更多的以往数据和经验来做支持的！所以，必要的数据准备是肯定的。
Step 2、Step 3、Step 4 未完待续...