Your Microservices Are a Distributed Monolith and You're Not Google

I've consulted for six startups in the last two years that "needed microservices for scale." Five of them had fewer than 50,000 daily active users and ran their entire platform on a single db.r6g.xlarge instance that sat at 12% CPU. They didn't have a scaling problem. They had a coupling problem—and they solved it by adding network latency, distributed tracing complexity, eventual consistency bugs, and a DevOps burden that required a platform team of four just to keep the lights on.

Build a modular monolith first. Enforce boundaries with package-private modules, separate database schemas, and explicit internal APIs. Deploy it as a single unit. Scale it vertically until the write path actually bottlenecks (hint: it's usually the database, not your application code). When you hit a genuine, measurable hot path—then extract that one service. Not before. Not "because the team is growing." Team scaling is an org problem; solve it with code ownership and CI/CD pipelines, not Kubernetes namespaces.

The industry has spent a decade selling you infrastructure you don't need because it's profitable for cloud providers and makes for great conference talks. Your users don't care about your service mesh. They care that the checkout page loads in under 200ms. Ship the monolith. Sleep at night.