2025 年，Patreon 面临了一个经典的工程挑战，那就是如何在为超过 1000 万名付费会员持续交付新功能的同时，重建支撑这些服务的底层基础设施。Patreon 工程团队在其工程博客上发布了文章“年度回顾：来自 12 个项目的经验教训”，详细记录了这一过程。
Idea Link 在 2025 年 5 月发布了一份关于软件开发真实成本的报告，该报告显示，初始软件构建仅仅是“冰山一角”，在软件的整个生命周期中，50%至 80%的成本实际上都花在了维护上。Patreon 最近发布的这份年度回顾正是这一经济现实的生动例证。面对 30 多万名活跃内容创作者和数百万订阅用户，该平台 2025 年的工程主线并非新功能开发，而是完善性维护（perfective maintenance）与存量系统演进（brownfield evolution）。这篇回顾详述了 12 个重大项目，并提炼出三大核心架构主题：韧性迁移模式、面向基数扩展的数据模型重构，以及分布式系统中的一致性权衡。
在将 50TB 的生产数据从自管理的 EC2 MySQL 迁移至 Amazon Aurora 的过程中，Patreon 无法承受传统“整体迁移”（lift-and-shift）方式所带来的停机风险。团队采用了一种防御性迁移策略，即在保留旧有 EC2 集群作为故障安全回退路径的同时，建立向新 Aurora 集群的复制流。事实证明，这种架构方面的冗余至关重要，当 Aurora 的 general.log 中一个冷门配置意外引发新主库延迟激增时，团队立即触发回切机制，无缝切换回了 EC2 路径，保障了系统的可用性。类似地，在移除一个深陷多年技术债务的旧版 React Router 时，团队采用了守门人（Gatekeeper）模式。由于缺乏对该遗留代码的专业级知识，工程师首先构建了专门的可观测性和功能开关（feature-flagging）基础设施。这使得他们能够逐步将流量路由至新的 Next.j 架构，在确认功能对等后，才最终下线旧路由器。
另外，还有大量工程投入用来打破限制产品发展的刚性 1:1 数据关系。例如，Multiple Podcasts 项目迫使团队重构了沿用十多年、默认“每位创作者对应一个 RSS 源”的核心身份模型。在启动任何前端工作之前，工程师必须先在后端数据库结构中将 feed 实体与 user 实体解耦。 在另一个项目中，“订阅赠送”功能的引入打破了计费引擎中原有的二元状态假设（即用户要么有订阅，要么没有）。为此，架构师重新设计了计费状态机，使其能够支持并发的订阅状态，例如，某名用户可同时拥有一个自费的个人订阅和一个他人赠送的订阅。这一变革实质上将系统从单一状态模型升级为分层权益模型（layered entitlement model），为更灵活的订阅场景奠定了基础。
最后一个核心主题聚焦于在分布式系统中主动选择一致性方面权衡。在 Patreon 的回顾文章中，明确引用了 CAP 定理，并描述了多个优先保障一致性而非吞吐量的场景。例如，在 Autopilot 营销引擎中，数据不一致的风险被视为不可接受。团队因此放弃了高吞吐的批处理模式，转而采用基于收件人的原子事务模型。该设计虽然牺牲了单条记录的处理速度，但确保了数据库写入与发送邮件操作之间的一致性，彻底消除了“幽灵重试”问题。此外，为提升创作者数据分析的灵活性，团队还实施了转换层模式（Transformation Layer）。该层充当面向前端的后端（BFF，Backend for Frontend），将原始数据获取与 UI 展示逻辑解耦，并作为数据清洗与标准化的唯一可信源（single source of truth）。
原文链接：
