# Monolith → modular → microservices decision checklist (July 2026)

Use before splitting services on AWS. Prefer **modular monolith** until a module needs independent scale, deploy cadence, or data ownership.

## Preconditions for any split

- [ ] Domain boundaries known from a **shipped** monolith (or clear bounded contexts)
- [ ] Each proposed service owns its data (no shared writable DB)
- [ ] Deploy independence test: can ship service A without coordinating B’s release?
- [ ] Observability ready: correlation IDs + distributed tracing budgeted
- [ ] Platform tax accepted: more CI pipelines, secrets, IAM roles, runbooks

## Prefer stay monolith / modular when

- [ ] Team ≤ ~8 engineers owning the whole product
- [ ] Scale-in-place still works (pools, replicas, cache, queues)
- [ ] East-west traffic would dominate without clear latency budget
- [ ] You cannot staff on-call per critical service

## Prefer extract service when

- [ ] One module needs different scaling / SLOs / tech stack
- [ ] Blast-radius isolation is a compliance or reliability requirement
- [ ] Independent deploy cadence unblocks two product teams

## AWS defaults (opinionated)

| Stage         | Compute                       | Data                        | Connectivity                                                   |
| ------------- | ----------------------------- | --------------------------- | -------------------------------------------------------------- |
| Monolith      | ECS/Fargate or single EC2 ASG | One RDS/Aurora              | ALB                                                            |
| Modular       | Same                          | Schema-per-module in one DB | ALB                                                            |
| Microservices | ECS/EKS/Lambda mix            | DB per service              | HTTP + EventBridge/SQS; VPC Lattice when mesh tax is justified |

## Counter-case

If the split is **political** (org chart as architecture), budget Lattice/mesh + platform engineers first — or refuse the split.