Monolith vs microservices
Whether a backend is one deployable application or many small services talking over the network, and when it makes sense to split.
Updated October 2026 · with examples from our own builds
What does monolith vs microservices mean in practice?
A monolith keeps the whole backend in one codebase and one deployment. Microservices split it into separate services, each deployed on its own, that call one another. Between the two sits the modular monolith: one deployment with firm internal boundaries that can be split along those lines later.
Most new products are cheaper to build, test and run as one well-organised backend. Splitting earns its keep when parts of the system genuinely have different jobs or owners, such as a phone backend that runs timers and a web backend that serves an admin console.
Every split adds a seam that can drift. Two services sharing data must agree on what each record means, and that agreement needs checking by a tool, not by memory.
Monolith vs microservices at a glance
- Default for a new product
- One backend with clear internal modules
- Split when
- Parts have different jobs, loads or owners
- Hidden cost of splitting
- Keeping shared models and contracts in sync
Where has monolith vs microservices come up in our builds?
Our recommendation for the replacement system is a modular monolith on PostgreSQL, with company and branch on every row and a background queue for filings and exports. It is a recommendation, not a decision; nothing has been built.
We split the system along its real seams: a mobile backend for everything a phone touches, and a web backend for the business portal, the developer API, invoicing and the console. Both share one MongoDB database, and the models they share are kept byte-identical and diffed by our tools.
The web backend answers requests and schedules nothing; the phone backend owns every timer. On 17 October 2026 we found the drift checker had compared only a hand-kept list of 50 files, leaving 22 shared files unchecked, and it now compares every file present in both backends.
Common questions about monolith vs microservices
Should my startup use microservices?
Rarely at the start. One backend with clean internal modules is quicker to build and cheaper to run. Split a part out when it has a genuinely different job or load, and plan how shared data will stay consistent before you do.
What goes wrong when two backends share one database?
Each side can start reading a record differently from the other. Keeping the shared models identical, and checking that with a tool before commits, is what stops one backend writing data the other misreads.
Related terms
Sources
Planning a product and not sure where monolith vs microservices fits? Ask us, or browse all 116 terms in the glossary.