Monolith or microservices? A pragmatic approach to architecture
Microservices promise scalability, but they come at a price. We explain when a well-designed monolith is the better choice and how to prepare your system for splitting later.
“Monolith or microservices?” comes up in many first meetings, often with the assumption that microservices are modern and a monolith is outdated. In practice, the choice of architecture should follow from team size, product maturity and real scaling needs — not from trends.
What microservices actually give you
Microservices let you deploy and scale parts of the system independently. They shine when several teams develop different product areas and parts of the system have very different loads — for example a reporting module crunching millions of records next to a simple admin panel.
The hidden costs
Every service means a separate deployment, monitoring, logs, API versioning and handling network failures. Transactions spanning several services become hard, and debugging requires distributed tracing. For a team of a few people, this overhead can consume more time than building business features.
A modular monolith as a sensible start
For most companies, the best starting point is a modular monolith: one application and one deployment, but with clearly separated modules that talk to each other through defined interfaces. Such a system is easy to maintain, cheap to host and quick to develop — without turning into a “big ball of mud”.
When to extract a service
- a part of the system needs a different scale or technology (e.g. video processing, AI models),
- a separate team develops that area on a different release cadence,
- a failure of the module must not stop the rest of the system,
- legal requirements demand data isolation.
If module boundaries are well designed, extracting such a part into a separate service takes weeks rather than a full rewrite.
What we focus on in our projects
Whatever the architecture, we follow a few rules: every module owns its data model, communication happens through explicit contracts, and deployments are automated. This keeps the decision to split open for later — when it is driven by data rather than predictions.
Summary
Microservices are a tool, not a goal. For a young product and a small team, a well-structured monolith that can be split gradually is usually the better fit. If you are weighing the architecture of a new system or modernising an existing one, we will be happy to help you assess the options.