intermediate
Monolith
Use one deployable when domain boundaries are still changing, team coordination is close, and operational simplicity matters more than independent scaling.
A monolith ships as one deployable with shared runtime, database, and release cadence. It minimizes operational overhead, simplifies debugging, and supports fast refactors when domain boundaries are still emerging. Many successful products stay monolithic longer than fashion suggests if team coordination is tight.
On interviews: argue when to start monolithic and what signals suggest splitting later. Mention modular internal structure without microservice ops tax.
Common pitfalls: blaming the monolith for bad modularity; skipping tests because deployment is single; scaling the entire app for one hot endpoint.
The trade-off is flexibility versus complexity—know when the simpler path is enough.
Checklist:
- Enforce internal module boundaries early.
- Monitor which areas drive scale needs.
- Keep deploy pipeline fast despite size.
- Document criteria for future service extraction.