Should I start a new project with microservices?

Short answer: probably not. For most greenfield products, the right starting point is a well-modularised monolith.

Short answer

The real problem microservices solve isn’t technical, it’s organisational: independently deployable parts, owned by separate teams, that need to scale at different rates. If you’re a solo developer or a small team and the domain hasn’t fully settled yet, you have none of those problems.

Why

1. You pay the cost up front and collect the benefit later. Network latency, partial failures, distributed transactions, observability and deployment complexity are billed from day one; the need to scale parts separately arrives months later — or never.

2. A boundary drawn before the domain settles is drawn wrong. Placing a service boundary while you’re still learning what the product is means casting that boundary in concrete, over the network.

3. Fixing a wrong service boundary is harder than extracting from a monolith. People say “extracting a service from a monolith is hard” — and it is — but extracting from a monolith with clean boundaries is far easier than fixing service boundaries you drew wrong from day one.

What to do

1. Start with a modular monolith. Split the domain into clear bounded contexts, but keep them in a single deployable application. Route inter-module communication through explicit interfaces — never reach straight into another module’s tables.

2. Enforce the boundaries in code. Don’t allow circular dependencies between modules. That discipline does most of the work in advance for the day you actually need to extract a module into a service.

3. Split when you’ve measured the pain. When a module genuinely has to scale separately, when a distinct team owns it, or when deploys start blocking each other — that’s when you promote that boundary into a service. I walked through how to run that day in peeling the payment module off a monolith with Strangler Fig.

Bottom line: microservices aren’t a goal; they’re a cost you pay at a certain scale, so don’t start paying it before you reach that scale. I’d start with a modular monolith, enforce the boundaries in code, and promote a module to a service only when measured pain shows up. I unpack the full architectural reasoning on sade.dev.