Stop Writing Microservices

Microservices are the wrong default for most companies. The architecture I keep coming back to is the modular monolith - the same Spring Boot codebase, organized strictly along domain boundaries, deployed as one.

Microservices won the marketing war. They're losing the architecture war.

I'm not saying microservices are wrong. I'm saying they're wrong for ~80% of teams that pick them.

What you're really paying for

When you split a monolith into services, you trade:

• Local function calls → network calls (with their own failure modes)
• Single deploy → orchestrated multi-deploy
• One database → distributed data with consistency challenges
• One observability story → distributed traces + per-service logs
• Refactoring across boundaries → cross-team alignment to refactor

For each service, you've added: a CI pipeline, a Dockerfile, a Kubernetes manifest, an SLO, a runbook, a security review, and a person responsible.

If your team has 6 engineers and 4 microservices, you've got more services than people. That ratio is upside-down.

The modular monolith

What I actually recommend: one Spring Boot (or Next.js, or Django) codebase. Internal modules with strict boundaries. Module A cannot import module B's internals - only its public interface. CI enforces this with ArchUnit or equivalent.

Same database, but module A only writes to module A's tables. Module B reads via module A's API, never directly from the table.

You get:

• 90% of the boundary clarity of microservices
• Local function calls (fast, simple, debuggable)
• One deploy, one log stream, one observability story
• Refactoring across boundaries is just refactoring

When you genuinely need to extract a service (it has a different SLA, a different scale profile, different language requirements) - the boundaries are already there.

When microservices ARE right

• Independent scaling per domain (real, not aspirational)
• Different language/runtime per domain
• Different release cadence per domain
• Genuinely separate teams owning genuinely separate domains
• You're at scale where the costs of coordination between services > the costs of coordination on a monolith

What banking taught me

DBS and TD both have services. They also have modular monoliths. The smart teams use the right tool. The teams in trouble - the ones with 200 microservices and three engineers per service - are usually the ones that picked microservices for marketing reasons.

Don't let your architecture be a hiring brand decision. Let it be an engineering decision.

References

• Modular monolith pattern
• ArchUnit
• Shopify majestic monolith