Microservices are not a universal solution. Before splitting your application into dozens of services, ask the right questions about your context, team and time horizon.
The microservices trend has swept the industry to the point where starting a project as a monolith has almost become shameful. This is a mistake in perspective. Amazon, Netflix, Uber migrated to microservices after years of growth — not from the start. Their operational complexity is massive: orchestration, network latency, distributed consistency, observability. For a team of five developers, this is often counterproductive.
A well-structured monolith — what Martin Fowler calls the Modular Monolith — offers the best of both worlds in the early stages. Modules are logically decoupled, independently testable, but deployed together. When a part of the system needs to scale differently, you can extract that module as an autonomous service using the Strangler Fig Pattern: build the new service in parallel and gradually redirect traffic.
The real selection criterion isn't technical — it's organizational. Conway's Law applies perfectly here: your architecture will resemble your team structure. If you have autonomous teams, each owning a business domain, microservices make sense. If you have a single versatile team, a modular monolith will be more effective.
→ See also: Domain-Driven Design · Microservice communication · Event-driven architecture