What this prompt does
This prompt forces ChatGPT into an architecture review mode rather than a generic explanation mode. By requiring you to state your current services, communication method, data stores, and pain points upfront, it eliminates the vague "it depends" response and produces targeted recommendations against your actual system. The "be opinionated" instruction at the end is load-bearing — without it, models hedge. With it, you get direct verdicts: your service is a god service, your database is shared incorrectly, your sync calls should be async.
The decomposition strategy variable ([decomposition_strategy]) is what separates this from a generic microservices Q&A. Plugging in "Domain-Driven Design bounded contexts" gets you different boundary recommendations than "team ownership" or "strangler fig migration" — and all three are valid depending on where you are in your migration.
The seven-section structure mirrors how a real distributed systems review works: boundaries first, then communication contracts, then data consistency (the hardest part), then anti-pattern detection, then cross-cutting concerns. You get a complete picture, not just the section you thought to ask about.
When to use it
- You are decomposing a Laravel or Rails monolith and are not sure where to cut service boundaries.
- You have services that constantly call each other synchronously and suspect you have a distributed monolith.
- You are designing a new event-driven system and need to choose between saga choreography and orchestration.
- You inherited an existing microservices setup and need a structured audit before adding more services.
- You are preparing for a technical design review or architecture decision record (ADR) and want a second opinion.
- You are onboarding a new team member and want a clear description of the target architecture.
Example output
Service Boundaries:
OrderService (✓) — clean, owns order lifecycle
InventoryService (✗) — god service: also handles pricing and promotions, split required
NotificationService (✓) — single responsibility
Communication:
Order → Inventory (stock check): currently sync REST → convert to async event
Reason: inventory check on checkout creates coupling; use reserved-stock event pattern
Data Consistency:
Cross-service order+inventory: use choreography-based saga
Compensating transaction: release reserved stock on payment failure event
Anti-Patterns Detected:
- Shared `products` table accessed by 3 services — critical, breaks independent deployability
- OrderService calls InventoryService calls PricingService in chain — chatty, 3-hop latency
Architecture Diagram:
API Gateway → OrderService (owns DB: orders)
↓ publishes: OrderPlaced event
InventoryService (owns DB: inventory) ← subscribes
PricingService (owns DB: pricing) ← subscribes
Async bus: RabbitMQ / topic-per-domain
Sync only at edge: gateway → OrderService for checkout initiation
Pro tips
- Set
[decomposition_strategy]to match your team structure. Conway's Law is real — if two teams own one service, it will fragment. If one team owns five services, they will drift back toward a monolith. - For
[pain_points], be specific about failure modes, not symptoms. "Deployments break other services" is more actionable than "things are slow." - Run this prompt twice: once for your current state, once for your 12-month target state. Diff the outputs to build a migration roadmap.
- The circuit breaker recommendation will be generic unless you name your stack in
[system_type]. Specifying "Node.js with Axios and RabbitMQ" gets you library-specific guidance rather than conceptual descriptions. - After getting the architecture diagram section, paste it back into a follow-up prompt and ask ChatGPT to generate an OpenAPI contract or AsyncAPI spec for each service boundary — it bridges design to implementation.
