Start Boring. Scale Deliberately.
Nate's take on monoliths, microservices, and the agentic world
A Lightning Talk by Nathan — Nate-Land Studios
The World Has Changed. Good design hasn't.
AI coding agents are doing real work in real codebases. And it turns out they're remarkably good at it — when they can see the whole picture.
The thing that's good for junior engineers is also good for AI agents: being able to see the whole codebase without filing a ticket to another team.
tldr; The Smart Default
Nate's Take
Monorepo
Shared types. Visible contracts. Cross-cutting call sites. Refactor across domain boundaries in a single PR. Your agents — and humans — can see everything.
Monolith
Function calls instead of network hops. A single deployment surface. "What does this change affect?" is still an answerable question.
* Or better yet — make it modular. More on that shortly.
Starting here isn't naive. It's the choice that keeps your options open
The Three Forces
What's actually pushing your architectural decisions
Conway's Law
Your org chart is quietly writing your architecture. Siloed teams build hard walls. If your microservices diagram looks like your reporting structure, that's not a coincidence — it's causation. Reorganize first, then decide.
Legacy Headwind
Every historical decision is a current pushing against you. The temptation is to escape it by starting something new alongside the old. Usually you're not escaping the mess — you're duplicating it.
Greenfield Temptation
"What if we just extracted this one piece and did it right?" This is how most premature extractions start. A service spun up to escape technical debt, not because the physics demanded it. The new thing feels clean until it has to talk to the old thing.
Three Questions Teams Conflate
Treating microservice as the way you express a domain boundary is a shortcut. These are actually three separate problems.
1
Where does your code live?
Monorepo vs. polyrepo — a collaboration and context decision.
2
How is your code deployed?
Monolith vs. microservices — a deployment and scaling decision.
3
Where are your domain boundaries?
A design decision. Enforceable inside a monolith.
You Don't Need a Network Call to Draw a Boundary
Before you pay the deployment tax, ask whether softer tools get you 80% of the discipline:
Package structure
Module-level isolation.
Ownership files
CODEOWNERS and team accountability.
Import constraints
Explicit rules on who talks to whom.
Code review conventions
Human enforcement of domain boundaries.
Separate deployment is the strongest enforcement — and the most expensive. Match your enforcement to your actual problem.
The Modular Monolith
The missing middle ground
Embracing a modular monolith allows organizations to maintain simplicity while achieving scale, offering a pragmatic alternative to distributed microservices.
1
Shopify
With 2.8 million lines of Ruby, Shopify explicitly chose a modular monolith to handle Black Friday at global scale, proving the model's resilience.
2
Stripe
Powering hundreds of billions in payments with over 20 million lines of Ruby, Stripe continues to operate as a successful monolith.
3
Uber
After scaling to 4,500 microservices—dubbed the "Death Star" by engineers—Uber is now consolidating back to "macroservices," highlighting the complexity cost.
"Don't start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile."
When You Earn the Extraction
The bar should be high
Microservices become the right answer only when a piece of your system has genuinely different physics.
Different Scaling Law
40 GPU instances vs. two t3.mediums aren't the same problem.
Different Availability SLA
That seam is real. The physics demand a hard wall.
Different Team Ownership
A genuine need for autonomy — not just preference.
That's surgery with a clear indication — not architecture for architecture's sake.
The Distributed Systems Tax
Every extraction is a CAP theorem decision you're making at the architecture level
Network latency
Where you once had a function call.
Distributed failure modes
Partial outages, retry storms, cascading failures.
Versioned contracts
APIs that must be maintained across independent release cycles.
Harder observability
Context windows shrink for your agents. Traces span processes, logs need correlation — and your AI tooling loses the picture entirely.
Navigate the Current. Don't Fight It.
The paddler doesn't fight every current. They read the water, use force deliberately, and correct only when the physics demand it.
Your monolith is the boat.
Your service boundaries are reading the current correctly.
Extraction is a correction maneuver — precise, intentional, earned.
Start boring. Add complexity when it's worth it.
Microservices solve scaling problems. Monorepos solve collaboration problems. Service boundaries solve design problems. Know which problem you actually have.
Don't pay the distributed systems tax until the scaling math forces your hand.
NATHAN — FRACTIONAL CTO & ENGINEERING LEADERSHIP COACH
NATE-LAND.COM
Worth Arguing About
Should the CTO be making this decision? Or is this an engineering leadership decision that CTOs often wrongly grab? What's the right level?
Is your microservices architecture actually driven by scaling physics — or by org chart? Conway's Law cuts both ways.
How do you know when you've extracted too many services? What's your signal?
If you started today with AI coding agents as a first-class team member, would you make the same architectural choices you made three years ago?
Who owns the decision to consolidate? Extraction is celebrated. Consolidation is quiet. Why?