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)
Thank you for sharing this article!
As a Japanese engineer, I found it really interesting, especially the analogy using the duel between Musashi and Kojiro.
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