Tip: answer aloud for ~5 minutes before reading the solution.
Question
Your board and engineers want to "move to microservices" because the 8-year-old monolith slows delivery. As CTO, how do you decide whether to do it, how do you execute without a big-bang rewrite, and how do you record and communicate the decisions?
Step-by-step solution
Diagnose the real problem with data (lead time, deploy frequency, coupling hot spots, team contention) — microservices solve team/organizational scaling, not bad code.
If extracting: use the strangler fig — route via a facade, extract one capability at a time, start with a loosely coupled edge capability, then the high-value changing ones; decouple by domain (bounded contexts) and move the data with it.
Prerequisites: automated deploys, observability, on-call ownership per service.
Record decisions as ADRs (context, decision, consequences) in the repo; review significant ones openly.
Communicate in business terms: milestones, measured outcomes, explicit stop/continue checkpoints.
Final answer
Only split when data shows organizational/deployment bottlenecks; otherwise modularize. If splitting, do it incrementally with the strangler fig pattern by bounded context, data included, on top of solid platform prerequisites, and capture each decision in ADRs with measurable checkpoints.
Trade-offs & common mistakes
Big-bang rewrite; extracting services but sharing one database (distributed monolith).
Splitting by technical layer instead of business capability.