The "microservices good, monolith bad" narrative has led many teams to split their applications prematurely, creating distributed complexity that slows development and increases operational costs.
Start with a monolith. Seriously. A well-structured monolith with clear module boundaries can serve millions of users. It's simpler to develop, test, deploy, and debug. You can always extract services later when you have concrete evidence that a specific module needs independent scaling or deployment.
Extract to microservices when: one part of your application needs to scale independently (e.g., video processing needs 10x resources while user management stays flat), different parts need different deployment frequencies, or different teams own different parts and step on each other during deployments.
The extraction should be data-driven, not theoretical. If you can't point to a specific bottleneck that a service extraction solves, you're adding complexity without adding value. At Ethersofts, we've helped clients go both directions — splitting monoliths that outgrew their architecture and merging microservices that were split too early.