Insights / Architecture
Monolith or microservices: choose boundaries you can operate
Service boundaries create deployment, data, and on-call costs. Start with a modular application and split when independent ownership or scaling is measurable.
Kiran Bandarupalli · 2 Oct 2026 · 2 min read
Microservices can make independent deployment and ownership easier, but they also turn local calls into network calls and local transactions into distributed coordination. A monolith can be a strong architecture when it has clear internal boundaries and a team that can understand it.
Start with modularity
Separate domain responsibilities behind explicit interfaces inside one deployable application. Keep ownership of data and business rules clear. This provides room to change a module without introducing network failure, duplicated deployment configuration, or a new on-call surface.
Look for evidence before extraction
A module may be a candidate for a service when it needs independent scaling, a separate release cadence, a distinct security boundary, or a team that owns it end to end. Repeated contention over a shared codebase can also be a signal—but only if the domain boundary is understood.
Account for the distributed cost
Before extraction, define request timeouts, retries, idempotency, authentication between services, and what happens when a dependency is down. Decide how data is owned and how consistency works. Add tracing and service-level monitoring so an operator can follow a request across boundaries.
Keep the path reversible
Extract a narrow capability with a stable contract. Avoid splitting a transaction-heavy workflow across services until the business process can tolerate eventual consistency or has a deliberate coordination strategy. Keep the old path available until the new one is observed in production.
- Prefer a modular monolith when the domain and ownership model are still changing.
- Split when an operational or organizational constraint is concrete.
- Measure latency, failure rate, deployment independence, and maintenance load.
- Do not introduce a service solely to use a different programming language.
Architecture is a set of trade-offs, not a maturity ladder. The best boundary is one the team can explain, test, deploy, and support.