Every few years, the industry consensus swings. Monoliths are bad. Microservices are good. Then the pendulum reverses. Amazon writes a blog post about consolidating to fewer services. Suddenly monoliths are back.
The honest answer is that neither is universally better. The question is: what is right for your team, your scale, and your pace of change?
Start with a monolith if your team is small, your domain is not fully understood, and you are still finding product-market fit. A well-structured monolith is fast to build, easy to reason about, and far simpler to debug. You can always extract services later.
Move toward services when you have clear bounded contexts, different scaling requirements across subsystems, multiple teams that need to deploy independently, and the operational maturity to manage distributed systems.
The mistake is jumping to microservices prematurely because they feel more serious. Distributed systems add complexity — network partitions, distributed transactions, service discovery, and observability across multiple deployment targets. That complexity has to be justified by real organisational or scaling requirements.
The best architecture is the simplest one that solves your current problem without blocking your next one.
