I read Patrick Farry’s notes on Patreon's year in review. He pulled threads many of us know. He pointed to trade-offs, migrations, and the slow work of...
Monoliths, Microservices, and the Quiet Work of Reliable Architecture
I read Patrick Farry’s notes on Patreon's year in review. He pulled threads many of us know. He pointed to trade-offs, migrations, and the slow work of making systems reliable. I thought of my own years inside big tech. I thought of failures we fixed at 2 a.m. and of launches that went clean.
Why this matters
Companies chase speed. Teams chase autonomy. Architecture sits in the middle. Choose wrong and you pay in outages and chaos. Choose right and you move fast without breaking production. That is the heart of the Patreon piece. It’s also the heart of every conversation about scalable architecture in 2025.
Monolith vs microservices: not a religion
The argument is old. Monoliths give clarity and simplicity. Microservices give autonomy and scale. Both cost. Both benefit. The right choice depends on team size, release cadence, and failure domains.
I remember a monolith at my first big job. We shipped small changes in one codebase. We shipped fast. We also tripped over each other. Later, at Amazon, we split services to scale traffic. We paid the price in network fragility and operational overhead. That taught me this: architecture is policy plus practice. It is people and process as much as code. — Ermenildo V Castro ✨
Migration strategies that work
Rip-and-replace rarely works. Incremental migration does.
Start with the edges. Extract a contained service. Define clear contracts. Build strong tests around the old behavior. Route traffic slowly. Observe. Roll back fast.
At Zulily, we moved a payment flow piece by piece. We left the UI in the monolith while extracting the billing logic. That way we reduced blast radius. We gained confidence with every step.
Patterns I use: strangler pattern, anti-corruption layers, and consumer-driven contracts. These are practical. They keep teams from reinventing old bugs.
Resilience and observability: the twin pillars
Speed without visibility is dangerous. Resilience without testing is brittle.
Invest early in tracing, metrics, and proper logs. Implement circuit breakers and retries, but make them observable. Test chaos in staging. Watch how real traffic changes behavior.
At Google, I saw alert storms from a small misconfigured client. We added better dashboards and dependency graphs. The noise fell. Engineers could act. They made local fixes that prevented bigger failures.
Architectural governance that enables speed
Governance often gets a bad name. Done right, it accelerates progress.
Set clear standards for APIs, deploy practices, and change review. Keep the rules lean. Measure compliance with automation, not with paper reviews.
At Microsoft, governance saved a product launch. We had lightweight rules on backward compatibility. Teams followed them because the rules saved them debugging time later. That buy-in mattered more than enforcement.
Trade-offs and honesty
Every choice breaks something. Admit it early. Design for the likely failure modes. Build teams that own both the feature and the runtime.
A shift to microservices can reduce cross-team friction. It can also increase operational toil. Plan for that toil. Hire the people or buy the platform to handle it.
Practical checklist
- Map your service boundaries by business capability.
- Start small with the strangler approach.
- Add tracing and SLOs before you add more services.
- Automate API compatibility tests.
- Make rollback fast and routine.
Final thought
Architecture is humble work. It’s trade-offs and guardrails. It’s the daily craft of keeping systems both fast and safe.
I am Ernie Castro. I’ve been at Google, Microsoft, Amazon, and Zulily. I write from Seattle. I read Patrick’s piece and I see familiar choices. I see the same crossroads teams face today. Build slowly where it matters. Move fast where you can. Pray the systems hold. 🙏