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
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.
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.
Starting here isn't naive. It's the choice that keeps your options open
Three Questions Teams Conflate
Treating microservice as the way you express a domain boundary is a shortcut. These are actually three separate problems.
Where does your code live?
Monorepo vs. polyrepo — a collaboration and context decision.
How is your code deployed?
Monolith vs. microservices — a deployment and scaling decision.
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.
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 comes with a real bill. Know what you're paying before you sign.
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.
The Decision Framework
Start Boring
Monorepo & monolith; enforce boundaries by convention.
See Everything
Allow agents and humans full visibility before splitting.
Extract When Needed
Only separate services when scaling or latency demand it.
Don't pay the distributed systems tax until the scaling math forces your hand. Complexity should be earned, not anticipated.
Start boring. Add complexity when it's worth it.
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