In Japanese history, one duel is remembered not for spectacle — but for restraint.
Sasaki Kojiro arrived dressed for honor.
A long blade. A perfect stance. Ceremony, reputation, form.
Miyamoto Musashi arrived late.
No armor. No flourish. A wooden sword carved from an oar.
The duel ended quickly.
Not because Kojiro was weak —
but because Musashi understood something deeper:
fundamentals beat flash when conditions are uncertain.
Modern software architecture repeats this duel every day.
The Modern Kojiro: “We’ll Need Microservices to Scale”
Every startup eventually hears this sentence:
“We’ll need microservices to scale.”
Sometimes it’s true.
Most of the time, it’s said far too early — before scale, before product–market fit, before teams even know what they’re scaling.
Early startups usually look like this:
- 1–3 engineers
- unstable requirements
- no real traffic pressure
- limited budget
- rapid iteration cycles
Yet they reach for:
- Kubernetes
- service meshes
- distributed deployments
- multi-database strategies
- cloud abstractions layered on abstractions
This is Kojiro arriving in ceremonial armor to a fight that doesn’t require it.
Microservices solve organizational scale, not early-stage chaos.
At this stage, you trade:
one hard problem (code structure)
for five harder ones:network boundaries
deployment complexity
observability overhead
security surfaces
distributed failure modes
The blade is impressive.
The battlefield is wrong.
Musashi’s Choice: The Modular Monolith
Musashi didn’t reject swords.
He rejected unnecessary ceremony.
The architectural equivalent is a modular monolith.
A modular monolith is:
- one deployable application
- with strong internal boundaries
- and discipline, not wishful thinking
Key properties:
- single codebase
- single deployment
- clear module ownership
- no cross-module leakage
- explicit contracts between domains
Example structure:
/users
/domain
/service
/controller
/billing
/domain
/service
/controller
/analytics
/domain
/service
/controller
Each module:
- owns its data
- exposes interfaces
- hides implementation details
This is not “just folders”.
This is intentional separation —
Musashi’s wooden sword: simple, focused, deadly.
Why This Wins Early Duels
*Cheap to Run
*
You deploy once.
You monitor once.
You debug once.
Your infrastructure bill stays boring — which is a feature.
No clusters to babysit.
No service mesh to understand before shipping.
*Fast to Adapt
*
Early-stage requirements change daily.
A modular monolith lets you:
- refactor confidently
- change internals without ripple effects
- move fast without fear
Musashi didn’t commit to a single stance.
Neither should your architecture.
*Security Is Easier
*
One application means:
- fewer exposed surfaces
- simpler auth flows
- clearer data boundaries
Security is already hard.
Distributed security is harder.
*Team Clarity
*
Even with two developers:
- one owns auth
- one owns analytics
Responsibilities are obvious.
Ownership is visible.
No “who broke prod?” mysteries.
The Discipline That Makes or Breaks It
Musashi still trained relentlessly.
A modular monolith fails without discipline.
Rules that matter:
- no direct DB access across modules
- no importing internal services from other modules
- communication only through defined interfaces
- shared code lives in explicit shared layers
Break these rules and:
- you don’t have a modular monolith
- you have a tangled monolith with extra folders
That’s not Musashi.
That’s cosplay.
The Scaling Moment (Where Kojiro Loses)
Here’s what most people miss.
When scale actually arrives:
- traffic increases
- specific domains get hot
- team size grows
At that point:
- each module already behaves like a service
- boundaries are already enforced
- extraction becomes mechanical, not emotional
You can:
- containerize a single module
- deploy it independently
- move it to Cloud Run / ECS / Railway
- leave the rest untouched
No rewrite.
No panic.
No “three months to re-architect”.
The system evolves.
It doesn’t reset.
This is Musashi adapting mid-fight — not Kojiro trapped by form.
Why I Recommend This to Early Founders
Because it optimizes for:
- learning
- cost
- speed
- clarity
- future optionality
You’re not rejecting microservices.
You’re earning them.
Microservices are not a badge of seriousness.
They’re a tool — like Kojiro’s sword.
The most expensive architecture is the one you build
before you understand the problem.
Top comments (2)
Glad you liked it! I’ve been an admirer of Japanese culture and Musashi for a very long time as I was talking to a Early founder about architectural choices this analogy clicked