In 2025, Patreon faced a classic engineering challenge: how do you ship features for over 10 million paying members while rebuilding the infrastructure that serves them? The Patreon engineering team documented their Year in Review: Lessons From 12 Projects on their engineering blog.
According to a May 2025 report by Idea Link on the true costs of software development, the initial software build is just the “tip of the iceberg”, with 50-80% of total lifetime costs dedicated to maintenance. Patreon’s newly released review provides a clear example of this economic reality. With over 300,000 active content creators and millions of subscribers, the platform’s engineering narrative for 2025 was about perfective maintenance and brownfield evolution, rather than new development. The review details 12 major projects, revealing three core architectural themes: resilient migration patterns, data model refactoring for cardinality, and consistency trade-offs in distributed systems.
With 50TB of production data moving from self-managed EC2 MySQL to Amazon Aurora, Patreon could not afford the downtime associated with a traditional lift and shift approach. The team employed a defensive migration strategy, establishing a replication stream to the new Aurora cluster while keeping the legacy EC2 cluster active as a fail-safe. This architectural redundancy proved critical; when an obscure configuration in Aurora’s general.log caused latency spikes on the new primary, the team triggered an instant failback to the EC2 legacy path, preserving system availability. Similarly, the removal of a legacy React Router, entangled in years of technical debt, required a Gatekeeper pattern. Lacking institutional knowledge of the legacy code, engineers built specific observability and feature-flagging infrastructure first. This allowed them to route traffic incrementally to the new Next.js architecture, verifying parity before decommissioning the old router.
Significant engineering effort also went into breaking rigid 1:1 data relationships that constrained product growth. The Multiple Podcasts project forced a refactor of the core identity model, which had assumed one RSS feed per creator for over a decade. The team had to decouple the feed entity from the user entity in the backend schema before any frontend work could begin. In another project, the introduction of subscription gifting broke the binary state assumption of the billing engine. Architects had to redesign the billing state machine to support concurrent subscription states, such as a user having a paid personal subscription and a gifted subscription simultaneously, effectively moving from a single-state model to a layered entitlement model.
The final core theme centered on deliberately choosing consistency trade-offs in distributed systems. Patreon’s review explicitly references the CAP theorem, detailing instances where they prioritized consistency over throughput. For the Autopilot marketing engine, the risk of data divergence was deemed unacceptable. The team moved away from high-throughput batch processing to a per-recipient atomic transaction model. This design accepts higher latency per record to guarantee that the DB write and the send email actions remain consistent, eliminating the phantom retry problem. Additionally, to improve the flexibility of creator analytics, the team implemented a Transformation Layer pattern. This acts as a Backend for Frontend (BFF), decoupling raw data fetching from UI presentation and serving as the single source of truth for data sanitization.
