I have split commerce platforms into gateways, users, locations, orders, inventory, tax, waste, admin apps, POS apps, webhook platforms, and worker fleets. I have also watched teams “go microservices” and create a slower monolith with latency.
So let’s go hard on the real topic: modularity.
Microservices are one packaging of modularity. They are not modularity itself.
First principle: split by pain, not by fashion
A service boundary should earn itself. Pain that justifies a split:
- different scale characteristics (order ingest vs rare admin reports)
- different deploy cadence (POS extension release vs nightly reconciliation)
- different failure domains (checkout money path vs CSV export)
- different ownership (team A can ship without team B’s merge queue)
- different data life cycles (ephemeral events vs long specialty order state)
If you split because a conference talk said “one service per noun,” you will pay distributed systems tax for noun pride.
Modularity means contracts, not folders
A modular system has:
- Explicit inbound contracts (HTTP/GraphQL/events with versioning habits)
- Explicit outbound dependencies (no silent reaching into another service DB)
- Owned data (the order service owns order truth; others store references)
- Independent deployability (Docker image + pipeline + rollback story)
- Independent testability (domain tests without the whole galaxy)
If service B queries service A’s database “just this once,” you do not have microservices. You have a distributed monolith with extra steps.
What good modularity looked like on bigger builds
Domain slices with teeth
Users, locations, orders, business rules, and gateway routing each became a deployable with a reason to exist. POS and Admin apps consumed them instead of embedding every rule.
Specialty ops as modules
POS capture, associate portal, back-office, webhook platform, and cron fleets were separate deployables around one specialty domain. That modularity let us fix a cron without redeploying POS, and fix portal UX without touching webhook ack behavior.
Terraform modules as infrastructure modularity
Networks, ECS/Lightsail style hosting, Lambdas, and pipelines as modules meant environments were compositions, not copy-paste. Infrastructure modularity and app modularity reinforce each other.
Docker as the unit of modular truth
Each module ships an image. CI builds that image. Stage runs that image. Prod runs that image. Arguments about “what’s on the box” shrink.
Benefits you can take to leadership meetings
Parallelism without mystical coordination
Real modules let multiple engineers ship the same week without merging through one bottleneck file.
Blast radius control
A bad deploy in exports should not take down checkout. If it can, your boundaries are fake.
Teaching units
Juniors can own a module end to end: contract, domain, data, Docker, pipeline, runbook. That is how mentoring creates seniors.
Replaceability
Want to rewrite a portal in a newer Next major? Good modules make that a local war, not a company freeze.
Scale where it hurts
Scale the hot path. Leave the quiet admin tool humble. Homogeneous “scale everything” is how cloud bills become horror stories.
The costs you must budget or you are lying
Microservices modularity is not free:
- observability becomes mandatory (trace ids across webhook → queue → worker → API)
- local boot needs compose profiles and docs
- contract changes need discipline and communication
- distributed transactions become sagas, outbox patterns, or accepted eventual consistency
- ownership theater fails loudly (every module needs a human owner)
If your team cannot staff ownership, stay modular inside a well-tiered monolith until you can.
Modularity anti-patterns I will fight in review
- shared database across “services”
- one giant utility library that every service imports for business rules
- chatty sync call chains that recreate the monolith on the network
- events with no schema story and no replay story
- services split by frontend vs backend fashion instead of domain pain
- “temporary” cross-service writes that become permanent folklore
How 3-tier and microservices fit together
Inside each service: presentation / domain / data.
Across services: contracts and ownership.
Across runtime: Docker images and pipelines.
Across people: teaching and named owners.
Skip any layer and the architecture becomes a costume.
Leadership takeaway
Modularity is how companies grow engineering capacity without growing chaos.
Go hard on boundaries. Go hard on ownership. Go hard on deploy independence. Use microservices when the pain is real. Use 3-tier always. Use Docker to keep the modules honest.
If your diagram has twelve hexagons and one brain that understands them, you do not have a platform. You have a puzzle with a single solver. Teach the map. Split the pain. Ship the modules.