瘦子：当 Facebook / Twitter / Youtube（无论什么）从软件的基本概念发展到...更大（可能有 100,000 名用户？）时，它们是如何成长的？
中型 Web 应用程序是否存在“最佳实践”增长路径？
真正的问题：在指定或投标中型 Web 应用程序项目时，有什么大不了的？在本例中，我们将使用 PHP 框架，但似乎这些框架大多适用于任何语言。
所以核心应用程序的程序员（对我来说）是最明显的部分。我们获得了用于处理应用程序的用户管理、用户界面和特殊类。然而，在我看来，这还不到实际项目的一半。
最终，随着良好的增长，基础设施和元 UI 问题将成为您的主要关注点，对吗？
1) 基础设施：云应用空间、数据存储、多数据中心情况下的数据库同步。
2）语言和文化问题：让应用看起来“讨人喜欢”或至少在主要“文化市场”中可用
3）数据索引问题
4）API /互操作性问题（嵌入式应用程序ala facebook和最终用户和搜索引擎等主要参与者的数据外部访问）
...所以，我很确定我错过了其中的一半，而且我不知道它们的优先级如何。
这里接受的答案是我寻求答案的一个很好的起点。
扩展您列表中的第一项似乎非常关键，并且将帮助您确定您将面临什么样的扩展问题，甚至可以想象哪些技术类别可能有用。这样做也会触及第 3 项和第 4 项，因为它们是相互关联的。
以下是一大堆问题，可能会帮助您进入探索性思维以扩展您的可扩展性思想，这不是您问题的直接答案，但希望是一个起点：
您在应用程序中的功能是什么？他们是读重还是写重，或者两者兼而有之？当您查看数据时，它是否需要一直是实时最新的可能状态？或者可以延迟吗？能延迟多远？缓存有帮助吗？缓存是容易的部分，还要考虑如何使缓存过期，这就是困难所在。您正在使用的数据是什么样的？它是高度相关的，还是更像单独的文档？
您的性能要求是什么？- 该应用程序是否主要在后台生成报告并通过电子邮件发送出去？或者它是否需要在 Twitter 上显示所有当前推文的完美实时地图？来自用户的更新是否需要立即传播给其他用户？每个用户还是其中的一部分？它需要多快才能做到这一点？页面是否需要在 300 毫秒或 2 秒内加载？
外部服务是否有任何类型的限制，可能是请求限制或速率限制？这意味着您需要排队和批量处理请求。您的某些外部数据提供商向您发送数据的速度是否比您处理数据的速度快？您可能需要将其排队，您可能需要使系统的这一部分自行扩展，并使用可变数量的“工人”可以上下移动。考虑将“个人可扩展”原则应用于系统的其他部分，它在大型安装中会带来好处。
希望这会有所帮助:)