You inherit a 'microservices' system that's really a distributed monolith - shared database, synchronous call chains, lockstep deploys. Walk through a concrete plan to migrate it toward true service autonomy.

## The overall strategy The right overall strategy is an **incremental strangler-fig migration**, not a big-bang rewrite. A big-bang rewrite risks months of effort with no incremental value delivered, a large batch of untested architectural decisions, and a single high-stakes cutover where problems surface all at once with no easy rollback path. Start instead with **domain modeling**: use domain-driven design's bounded-context mapping to assign clear ownership of each entity or table to exactly one service. This determines the target end state before any code is touched, so subsequent steps have a destination rather than being ad hoc. ## Migrating one shared table For each table currently written by more than one service, pick a target owner and migrate in stages. 1. **Step one** is establishing a single writer: route all writes through the owner, so other services' writes go through the owner's API instead of raw SQL, while everyone still reads directly for now. This is comparatively low-risk because uncoordinated writes are what actually corrupts invariants, while shared reads against a still-shared physical database are comparatively safe during the transition. 2. **Step two** replaces direct reads by other services with either synchronous calls to the owner's read API for low-volume, real-time needs, or an event stream the owner publishes, such as `OrderPlaced` or `OrderCancelled` events, that other services consume to build their own local, denormalized read models — essentially **CQRS** applied across service boundaries, which also removes real-time coupling on the read side. 3. **Step three**, once no other service issues SQL against that table, physically moves it to a database only the owner can reach, typically by revoking other services' database credentials, completing the split for that entity. ## The synchronous call chains In parallel, address synchronous call chains. Identify which calls sit on the critical, user-facing path and genuinely must remain synchronous, such as a payment authorization, versus which were made synchronous only because that was the default when the module was extracted from the monolith. Convert the latter to asynchronous messaging so producer and consumer are decoupled in time. For any synchronous call that must remain during the migration, add timeouts, circuit breakers, and bulkheads to bound the blast radius while coupling is still partially present. ## Safety nets Safety nets matter throughout the transition. - **Consumer-driven contract tests**, such as those built with a tool like Pact, replace the safety a shared database's foreign keys and constraints used to provide silently, catching a breaking API or schema change before deploy rather than in production. - **Feature flags and dual-write-then-verify patterns** let a table be cut over to its new owner gradually, with the ability to roll back the read path if inconsistencies are detected, rather than forcing a hard, irreversible cutover. The best success metric is not a subjective sense of 'cleaner architecture' but the shrinking rate of **lockstep-deploy incidents** and cross-service on-call escalations — a falling rate is direct evidence that autonomy has genuinely increased, not merely that services were relabeled. ## Sequencing and the org chart Sequencing and organizational alignment round out the plan. Prioritize the highest-value, lowest-risk splits first: tables unambiguously owned by one team with few external readers are quick wins that build momentum and organizational trust in the approach, while the tangled, heavily-shared core tables, often something like a shared users or accounts table, are best tackled later once the team has practiced the pattern on smaller cases. This ties back to **Conway's Law**: real autonomy requires the team structure — who's on-call, who reviews pull requests, who owns the roadmap — to match the new service boundaries, not just the code. A common failure mode is completing the technical split while a single team still owns both resulting services, which quietly reintroduces coordination costs through shared humans instead of shared code. Large, well-documented decompositions at companies like Amazon followed roughly this incremental-ownership-migration shape — moving data ownership and call patterns step by step behind a stable interface — rather than rewriting the system from scratch.