Library · Architecture

Monolith vs microservices, honestly.

By Mokshify Engineering · Reviewed by the team · Updated 17 Jul 2026 · 6 min read

The problem

Teams adopt microservices for reasons that are usually organisational (many teams shipping independently) while paying costs that are always operational (distributed everything). Startups copying Netflix’s architecture without Netflix’s problems buy the costs without the reasons - the most expensive fashion decision in software.

Our default: the modular monolith

One deployable, containing modules with real boundaries: separate packages, explicit interfaces, no reaching across. You get monolith operations (one pipeline, one database, transactions that just work) with service-shaped code - and, crucially, a migration path: a module with clean boundaries extracts into a service in weeks; spaghetti extracts never.

When services genuinely win

Advantages, disadvantages, tradeoffs

Monolith-first advantages: operational simplicity, real transactions, refactoring across boundaries while they are still wrong (they always start wrong). Disadvantages: discipline must be cultural - nothing stops a lazy import except review; one bad deploy touches everything (mitigated by staged rollouts). Microservices advantages: independent deploys, per-service scaling and stacks. Disadvantages: distributed transactions, network failure modes everywhere, observability as a prerequisite, and an ops bill measured in engineers. The tradeoff we accept: occasional extraction work later, in exchange for not paying distributed costs before distributed benefits.

Technology selection

Boundaries enforced in code review (dual review), modules on the standard platform - PostgreSQL, Docker, Kubernetes when earned - and extraction, when it comes, along the strangler pattern we use for modernization.


Related: Multi-tenant SaaS · Background jobs · Engineering decisions · Architecture gallery