Library · Architecture
Monolith vs microservices, honestly.
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
- Independent team cadence - multiple teams whose deploys block each other; Conway’s law is real.
- Divergent scaling or runtime - the AI inference workload needs GPUs and Python while the API needs neither (our RAG pipeline is exactly this split).
- Genuine isolation requirements - a component whose failure or compliance profile must not share a blast radius.
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