Write a Monolith to Microservices Prompt That Finds Real Service Boundaries

The appeal of breaking a monolith into services is obvious. The danger is that a bad boundary is far worse than no boundary, because now you've got a distributed monolith: services that can't deploy independently because they share a database and call each other synchronously for everything. A monolith to microservices prompt is worth building because the hard question isn't "can we split this," it's "where, and in what order," and that's a judgment a prompt can structure but not finish.

The pages ranking for this either pivot to selling a platform or stay at the level of "AI can analyze your codebase." None hands you a copyable prompt that takes a real dependency map and returns risk-ranked boundaries with the shared-data conflicts called out. That's the gap.

Why a clean-looking split can be a trap

Code dependencies are visible. A static analysis shows module A imports module B, so they look coupled or not. What it misses is the shared table both modules write to, the implicit ordering between two operations, the transaction that spans what you thought were separate concerns. Split on the visible coupling alone and you get services that share a database and fail together.

The stance worth defending: the boundary that matters is the data boundary, not the code boundary. Two modules with no shared imports can still be inseparable if they both own rows in the same table. A decomposition prompt that only reads code structure will propose splits that look clean and aren't. It has to reason about data ownership, and where it can't, it has to flag rather than assert.

What a monolith to microservices prompt does

A monolith to microservices prompt is a boundary proposer that reads a module and dependency map, ranks candidate service boundaries by coupling and risk, flags shared-data conflicts, and outputs a strangler-fig extraction order against a contract. It proposes the split and surfaces what it can't be sure of.

Run it to:

• Group modules into candidate services by cohesion and coupling
• Flag every table written by more than one candidate service
• Rank boundaries by extraction risk, lowest-risk first
• Propose a strangler-fig order so one service extracts at a time
• Mark synchronous call chains that would become network hops
• Flag implicit coupling it can't verify, for human review

The shared-data flag and the extraction order are the two things the thought-leadership pages skip.

Anatomy of the prompt

Variables
  {{module_map}}        → modules and their responsibilities
  {{dependency_graph}}  → who imports/calls whom
  {{data_access}}       → which modules read/write which tables

Prompt
  Role: you are a monolith decomposition architect.
  Task: propose service boundaries from {{module_map}}.
  Rules:
    - Flag any table written by 2+ candidate services.
    - Rank boundaries by extraction risk; lowest first.
    - Flag implicit coupling you cannot verify; don't assert.

Output contract
  Return: boundary proposal + shared-data flags + extraction order.

1. Feed data access, not just code

The decomposition lives or dies on data ownership. Paste which modules touch which tables into {{data_access}} so the model can spot the shared-table conflict, which the dependency graph alone won't show.

2. Read the shared-data flags first

Before the boundary proposal, read what the model flagged as shared. A table written by two candidate services is a conflict to resolve before either extracts. That's the real work.

3. Follow the extraction order

The output ranks services by extraction risk and proposes a strangler-fig sequence. Extract the lowest-risk leaf first, prove the pattern, then move inward. Don't extract the central service first.

Prompt-craft patterns for decomposition

Rank by extraction risk, extract leaves first. A prompt that proposes all boundaries at once invites a big-bang rewrite. Force a risk-ranked order so you extract one low-risk service, learn, and proceed. The order is the deliverable.

Flag shared data as a blocking conflict. A table written by two candidate services isn't a detail, it's a reason the boundary isn't real yet. Make the contract treat shared-data ownership as a conflict to resolve, not a footnote.

Flag what it can't verify. Implicit coupling, runtime ordering, transactional spans. The model can't always see these. The safe move is a review flag, not a confident split. A wrong boundary asserted confidently is the expensive mistake.

Where Claude and GPT-4o diverge on boundaries

The models differ in confidence. Claude tends to flag implicit coupling and shared-data conflicts, and it hedges where the data access is ambiguous, which is the right instinct for an architecture decision. GPT-4o produces tidier, more confident boundary proposals that read well and can quietly bury a shared table unless the "flag data-ownership conflicts" rule is on the final line.

Neither model sees runtime coupling, the synchronous call that becomes a network dependency, the transaction that spanned two modules, so both should defer those to a review list rather than asserting independence. This is a place to be skeptical of a clean answer: a decomposition that comes back with no flagged conflicts on a real monolith is usually a sign the model didn't have the data access, not that the monolith splits cleanly. Restate the conflict-flagging rule for GPT-4o; pin the model version, because an architecture planner that grew more confident after an update is a liability when the boundary it asserts is wrong and you've already built it.

How this fits broader migration work

Decomposition is the architecture end of the same migration spectrum as a framework or database move. The staged, reversible discipline carries over: extract one service, verify, proceed. For the database side, where shared tables become per-service schemas, the safe database migration prompt handles the destructive-operation safety; for understanding the blast radius of a change across a split codebase, the monorepo impact analysis prompt maps what a change touches.

Variables you'll set

Getting started

1. Copy the structure into ChatGPT, Claude, or Gemini.
2. Describe your modules in {{module_map}}.
3. Add the data access in {{data_access}} so shared tables surface.
4. Run it and read the shared-data flags before the boundary proposal.
5. Resolve every data-ownership conflict before extracting anything.
6. Follow the extraction order, lowest-risk service first.

For a decomposition where the boundary analysis, data-ownership checks, and extraction sequencing are wired together, the Monolith-to-Services Decomposition Playbook runs the full sequence.

Once services are extracted, the API contracts between them become the thing that breaks consumers. The API Contract Test Harness Pack generates the tests that hold those contracts as boundaries shift. New to buying packs versus rolling your own? Start with how to choose a reusable AI prompt pack.