Twitter工程团队近期提供了Twitter核心技术的演进和扩展的详细资料，这些核心技术支撑了Twitter自营数据中心的系统架构，用于提供社会媒体服务。他们分享的关键经验包括：超越原始规格和需求进行系统架构，并在流量趋向设计容量上限时迅速做出大刀阔斧的改进；不存在所谓的“临时更改或变通方案”，因为变通方案会成为技术债务；聚焦于为任务提供适合的工具，但这意味合理领会所有可能的用例；对内部的和社区最佳实践的文档工作已成为一种“力量倍增器”。
根据近期Twitter工程博客上的一篇博文，Twitter作为社会网络和在线新闻服务创建于2006年，在那个时期，“统治数据中心”的是企业级实体厂商所提供的硬件。在Twitter运行的头十年中，快速增长的用户群已对硬件层提出了很多工程上的挑战。虽然Twitter在公共云上“运行良好”，但是他们已经开始重点投资自身的私营架构。至2010年，Twitter已从第三方的主机托管服务迁移到自身私营的数据中心架构，该数据中心架构在随后六年中“持续地设计和更新……有效地利用了技术和硬件的最新开放标准”。
至2010底，Twitter最终完成了首个内部网络架构，从设计上解决了在第三方主机托管架构中所遇到的扩展性和服务问题。最初，深度缓冲（Deep Buffer）机柜顶部（ToR，Top of Rack）交换机和电信级核心网络交换机的使用，使Twitter支持了2014年世界杯这样的全球事件所产生的前所未有的每秒交易（TPS，Transaction Per Second）量。在随后数年中，Twitter架构团队在五大洲部署了网络服务提供点 （PoPs，point-of-presence）。2015年，Twitter从传统的层次数据中心网络拓扑结构迁移到使用边界网关协议（BGP，Border Gateway Protocol）路由的Clos网络。Clos方法的显著优点包括：更小的设备单点故障的“波及范围”、更好的水平带宽扩展能力，以及由更低的CPU开销导致的更高路由性能。
在Twitter网络架构扩展的过程中，Twitter的工程团队汲取到一些重要的经验教训：
- 超越原始规格和需求进行系统架构，并在流量趋向设计容量上限时迅速做出大刀阔斧的改进。
- 根据数据和指标做出正确的技术设计决策，并确保这些指标可被网络操作人员理解。这对于托管主机和云环境是尤为重要的。
- 并不存在所谓的“临时更改或变通方案”的东西。在很多情况下，变通方案会成为技术债务。
在Twitter架构中，45%的规模用于存储和消息。架构团队为内部用户提供了多种服务，包括：Hadoop集群、Twitter的Manhattan （Apache Cassandra-esque）分布式数据库集群、FlockDB图存储集群（使用了Gizzard和共享MySQL）、Blobstore集群、Twemcache及“Nighthawk”共享Redis缓存集群、DistributedLog消息集群（用于Heron的处理）以及关系存储（MySQL、PostgreSQL和Vertica）。在2010年曾使用Cassandra作为度量数据存储的解决方案，但是在2015年4月启用Manhattan后，就禁用了Cassandra。
几乎全部的Twitter主缓存已从“裸机”迁移到大规模部署的开源集群管理系统Apache Mesos上（Twitter也是Mesos代码库的主要贡献者之一）。推文的时间线缓存Haplo是尚未部署到Mesos的最重要组件。Haplo使用定制版的Redis实现。对于该缓存，最严峻的挑战在于可扩展性和性能，因为Twitter运行上百个集群，合计包速率可达3.2亿包/每秒，每秒为客户提供120GB的内容。为达到高吞吐量和低延迟的服务水平目标（SLO，Service Level Objective），工程师要持续测量系统的性能，寻找优化效率的方法。例如，Twitter工程师创建了一个测试缓存性能的开源工具rpc-perf，使用它可以更好地了解各种负载场景下缓存系统的运行情况。
存储和缓存实现中的主要经验教训包括：