From 2015 to 2022, "Microservices" was the resume-padding buzzword of choice. Startups with 5 users were deploying 20 services via Kubernetes. It was complexity for complexity's sake. In 2026, the pendulum has swung back.
The "Distributed Monolith" Trap
Most companies didn't build microservices; they built a distributed monolith. They took function calls (which take nanoseconds) and turned them into HTTP requests (which take milliseconds) over a flaky network.
The "Whoops" Moment
"We spent more time debugging distributed tracing and managing Terraform state files than we did building product features." — Every CTO in 2024.
Enter the Modular Monolith
At elitics.io, we default to the Modular Monolith.
Single Deployment Unit
One CI/CD pipeline. One database (logically separated). Atomic commits.
Strict Boundaries
Code is organized into modules (Billing, Users, Inventory) that interact via public interfaces, not backdoor SQL joins. It enforces discipline without the network lag.
When to actually split?
We only extract a service when it has a vastly different scaling profile.
// Good reason to split:
"The Video Transcoding module eats 100% CPU and crashes the API server." -> Move to Worker Service.
// Bad reason to split:
"We want the User Profile team to have their own repo." -> Use a Monorepo.
Simplicity scales better than complexity. Don't build Google's infrastructure unless you have Google's problems (and budget).
Enjoyed this perspective? Share it with your team.