Transaction Boundary Analysis Prompt

This prompt is for backend engineers and architects who need to map transactional consistency boundaries across a business operation before implementation begins. The job-to-be-done is identifying which steps in a multi-service workflow must execute atomically and which can tolerate eventual consistency. Use it when you are designing a new cross-service operation, decomposing a monolith, or reviewing an existing distributed transaction for correctness. The ideal user brings a concrete business process description, a list of participating services or modules, and the data entities each step touches. Without these inputs, the prompt produces generic advice rather than an actionable boundary map.

The prompt produces a structured boundary map that distinguishes atomic transaction scopes from eventual consistency zones, with specific recommendations for saga patterns or two-phase commit per boundary. It also flags shared data dependencies, identifies potential consistency anomalies, and suggests compensation logic where sagas are appropriate. This is not a prompt for high-level architecture philosophy or generic microservice advice. It requires a specific, named business operation such as 'Order Fulfillment' or 'Claim Submission' with concrete steps. If you cannot enumerate the steps and the data they touch, you are not ready for this prompt. Use the Service Boundary Candidate Identification Prompt or Bounded Context Discovery Prompt for earlier-stage decomposition work.

Do not use this prompt when the operation is purely single-service, when you are designing greenfield event schemas without an existing process, or when you need a full saga implementation rather than a boundary analysis. The output is a design artifact, not executable code. For regulated domains such as payments, healthcare claims, or financial ledgers, always route the output through a senior architect review gate before implementation. The prompt identifies where consistency is required but does not replace formal correctness proofs or transaction isolation testing. Pair this with the Saga Orchestration vs Choreography Decision Prompt once boundaries are confirmed.

The following prompt template is designed to be copied directly into your AI harness, notebook, or prompt management system. It uses square-bracket placeholders for all dynamic inputs, allowing you to swap in your own business operation descriptions, system context, and output format requirements without modifying the core instruction structure. The template assumes you have already identified the business operation you want to analyze and have gathered relevant context about the services, databases, and integration patterns involved.

textCopy
You are a senior backend architect specializing in distributed systems and transactional consistency. Your task is to analyze a business operation and produce a transaction boundary map that distinguishes atomic transaction scopes from eventual consistency zones.

## INPUT
[BUSINESS_OPERATION_DESCRIPTION]

## SYSTEM CONTEXT
- Services involved: [SERVICE_LIST]
- Data stores per service: [DATA_STORE_MAP]
- Existing integration patterns: [INTEGRATION_PATTERNS]
- Current transaction boundaries (if any): [CURRENT_BOUNDARIES]

## CONSTRAINTS
- Latency budget per operation: [LATENCY_BUDGET_MS]ms
- Consistency requirements: [CONSISTENCY_REQUIREMENTS]
- Availability targets: [AVAILABILITY_TARGETS]
- Regulatory or audit requirements: [REGULATORY_REQUIREMENTS]

## OUTPUT SCHEMA
Produce a JSON object with the following structure:
{
  "operation_name": "string",
  "boundary_map": [
    {
      "boundary_id": "string",
      "boundary_type": "atomic_transaction | eventual_consistency",
      "participating_services": ["string"],
      "data_entities_modified": ["string"],
      "consistency_requirements": "string",
      "recommended_pattern": "saga | two_phase_commit | outbox | transactional_outbox | none",
      "compensation_strategy": "string or null",
      "failure_scenarios": ["string"],
      "rollback_complexity": "low | medium | high | impossible"
    }
  ],
  "cross_boundary_dependencies": [
    {
      "from_boundary": "string",
      "to_boundary": "string",
      "dependency_type": "synchronous | asynchronous | eventual",
      "data_flow": "string",
      "coupling_risk": "low | medium | high"
    }
  ],
  "distributed_monolith_risks": ["string"],
  "recommended_migration_steps": ["string"],
  "open_questions": ["string"]
}

## INSTRUCTIONS
1. Identify every data mutation step in the business operation.
2. Group steps that must succeed or fail together into atomic transaction boundaries.
3. For each boundary, determine whether a saga, two-phase commit, or simpler pattern is appropriate based on latency, availability, and rollback complexity.
4. Flag any boundary where the recommended pattern conflicts with existing system constraints.
5. Identify cross-boundary dependencies and assess coupling risk.
6. Surface distributed monolith risks where boundaries are drawn too tightly or share synchronous dependencies.
7. If regulatory or audit requirements exist, note any boundaries that require additional evidence capture or human approval.
8. If any boundary has rollback_complexity of "impossible," flag it as requiring human review before implementation.

## RISK_LEVEL
[RISK_LEVEL]

If RISK_LEVEL is "high," include a human_review_required boolean field in each boundary object and set it to true for any boundary with rollback_complexity of "high" or "impossible."

To adapt this template, replace each square-bracket placeholder with your actual data. The [BUSINESS_OPERATION_DESCRIPTION] should be a detailed narrative of the operation, including the sequence of steps, the services involved, and what data changes occur. The [SERVICE_LIST] and [DATA_STORE_MAP] provide the architectural context the model needs to reason about where data lives. The [CONSTRAINTS] section is critical for realistic recommendations—a 50ms latency budget will rule out two-phase commit, while strict consistency requirements may rule out eventual consistency. The [RISK_LEVEL] placeholder controls whether the output includes explicit human review flags. For production use, validate the output JSON against the schema before acting on the recommendations, and always have a senior engineer review boundaries marked as high-risk or with impossible rollback complexity.

The Transaction Boundary Analysis prompt is designed to be called programmatically as part of an architecture review pipeline, not as a one-off chat interaction. The prompt expects a structured [BUSINESS_OPERATION] description and returns a boundary map with atomic transaction scopes, eventual consistency zones, and protocol recommendations. In production, you should wrap this prompt in an application harness that validates the output schema, retries on malformed responses, logs every invocation for auditability, and routes high-risk or ambiguous outputs to a human reviewer before the boundary map is committed to an architecture decision record.

Start by defining the input contract. The [BUSINESS_OPERATION] field should be a structured object containing the operation name, a step-by-step description of the business process, the participating entities or aggregates, and any known consistency requirements. If you have existing domain models or event storming outputs, include them in [CONTEXT] as structured JSON or a concise summary. The [CONSTRAINTS] field should specify latency budgets, regulatory requirements, and team topology constraints that will influence saga vs. two-phase commit recommendations. On the output side, enforce a strict JSON schema that includes boundary_id, boundary_name, participating_entities, consistency_type (atomic or eventual), recommended_protocol (saga, 2PC, or outbox), rationale, and risk_notes. Use a schema validator immediately after the model response to catch missing fields, type errors, or invalid enum values. If validation fails, retry once with the validation errors appended to the prompt as feedback. If the second attempt also fails, escalate to a human reviewer and log the failure for prompt improvement analysis.

Model choice matters here. Use a model with strong reasoning capabilities and reliable structured output support, such as Claude 3.5 Sonnet or GPT-4o with structured outputs enabled. Avoid smaller or older models that may conflate transaction boundaries or produce inconsistent protocol recommendations. Set temperature low (0.0–0.2) to reduce variance in boundary decisions. If your organization requires evidence grounding, pair this prompt with a retrieval step that pulls relevant ADRs, existing service boundary documentation, or database schema metadata into the [CONTEXT] field before invocation. For teams running this analysis repeatedly across multiple business operations, cache the prompt prefix with consistent system instructions and schema definitions to reduce latency and cost. Log every invocation with the input hash, output boundary count, validation status, and reviewer decision to build a traceable audit trail for governance reviews. Never treat the model's output as a final architecture decision without human review when the operation involves financial consistency, regulatory compliance, or irreversible data mutations.