开发人员在任何软件项目过程中都会做出数百个微观和宏观决策。有些似乎相对无害，但对下游会有一个很大的影响。几位Cantina工程师聚在一起，回顾了我们在学习了一些艰苦的经理后需要特别考虑的关键点。
1. 利益相关者要求
您作为架构师或系统设计师的首要任务几乎总是让所有必要的利益相关者尽快发现需求。
这些需求在项目的初始阶段可能是最难获得的。虽然这种担忧通常与看似最后一刻的审计和安全要求有关，但请记住上下文规则。
2. 数据读/写伸缩平衡
在决定如何构建可伸缩Web应用程序时，关键的首要决策是了解数据存储可能需要的读写平衡：
- 重型写：应用程序在扩展时会遇到一致性问题，因此应尽早注意模型的写入完成，数据分发和各种批处理过程。像Twitter和其他人这样的大量应用程序通常采用流式写入模式，将消息传递作为支持可伸缩写入语义的主干。利用发布/订阅（pub / sub）和Google Spanner等并发概念可以提供帮助。（还记得：日志和数据库只是彼此的对偶）。
- 繁重读：此类应用程序可能是随着它们的增长而最容易扩展的。有许多开箱即用的技术可以促进这种模式，包括许多缓存机制，高性能键值存储以及MongoDB等流行存储系统的复制只读节点。
3.数据一致性
我们中没有一个人可以逃脱CAP定理!
但只有在出现系统故障，网络故障或其他无法满足三元组的分区（P）元素时才会发挥作用。在这种情况下，应用程序设计人员和架构师必须提出一个棘手而棘手的问题：这个产品可以更好地容忍哪些，一致性失败或可用性失败？
- 一致性 - 如果您的应用程序可以同时访问不同节点的不同状态，那么一致性并不是最重要的。当向两个不同的用户显示社交媒体馈送时会出现这种情况，每个用户的结果略有不同。
- 可用性 -如果追求总是能返回结果，NoSQL运动的数据存储解决方案或实施BASE语义将是可行的选择。但是，如果同时为所有同时请求（想想金融交易，银行，证券交易所）提供正确和相同的答案也很重要，那么一致性是最重要的，最好不要返回错误的结果。这有时会产生昏昏欲睡的结果响应或锁定状态，但通常值得花费正确的响应。在这种模式中，具有ACID语义的传统关系数据库系统通常是应用程序设计的必要初始选择。
4. 领域/数据模型
在考虑指定系统应该是什么业务领域时（参见域驱动设计），应该考虑系统的上下文 - 允许通过系统传递的非上下文固有的信息作为文档而不是作为领域模型的一部分。
例如，采用一个系统将天气数据返回给用户，但该系统也从另一个第三方服务获取该数据。
解决方案可能会寻求保持从第三方返回的数据，并将其领域复制为自己的领域。这将迫使架构管理一个更复杂的领域，该领域具有许多可能永远不会使用的关系，但必须随着时间的推移而维护。
通过将较小的关系数据库与文档存储相结合，它还将模糊改善数据访问性能和简单性的潜力。
像这样的问题可以通过端口和适配器等范例来解决。通过完全理解系统的领域而不包括领域环境不固有的信息，架构师能够做出能够极大地提高设计性能和可维护性的存储技术决策。
5. 负载的可变性
在灾难或公共事件期间接收大量负载峰值的API（例如Facebook）将具有与从空气质量传感器接收预期的每小时度量标准的要求截然不同的要求。
利用可以有效计量请求的体系结构（队列，热表等）可以缓解这些问题中的一些问题。
如果数据一致性不是系统中最重要的问题（如前所述），那么复制数据系统可以帮助在请求进行负载平衡或智能路由时保持单一入口点的压力。
虽然无服务器计算提供了诸如内置扩展等显着优势，但它需要更多纯函数的无状态代码结构。对于新系统的绿地greenfield实施，这可能没问题，但迁移遗留系统可能是一个挑战。