Orchestration vs Choreography Saga Pattern Prompt Template

This prompt is designed for architects and platform engineers who have already identified a business transaction boundary that spans multiple services and need to commit to a coordination strategy. The job-to-be-done is producing a trade-off memo that compares orchestration and choreography across dimensions that matter in production: visibility into transaction progress, coupling between services, failure recovery complexity, testing difficulty, and team autonomy. It is not a tutorial on sagas, nor does it generate implementation code. The output is a decision document that helps you and your stakeholders choose a pattern with eyes open to the operational consequences.

Before using this prompt, you must have a clear understanding of the participating services, the transaction steps, and the compensating actions required for rollback. The prompt assumes you can articulate the business transaction boundary and the failure modes you care about. If you are still exploring whether a saga is even necessary—for example, you are debating between a distributed transaction and a single-service operation with idempotent retries—this prompt will not help you make that higher-level decision. Similarly, if you have already committed to a specific saga framework (such as Temporal, Camunda, or AWS Step Functions) and need framework-specific configuration, this prompt is too general. Use it when the architectural choice is still open and you need a structured comparison to prevent advocacy-driven decisions.

The prompt is most effective when you provide concrete context about your system: the number of services, the expected transaction volume, the latency budget, the team topology, and the observability tooling already in place. Vague inputs produce vague trade-off memos. If you cannot describe at least two failure scenarios that worry you (e.g., a compensating action fails, a service is unreachable mid-saga), pause and define those before running the prompt. The output will include eval checks for hidden temporal coupling and unstated assumptions, but those checks are only as good as the context you provide. After running the prompt, review the output for any dimension where the model made an implicit assumption about your system—these are the places where the analysis is most likely to be wrong.

This prompt template is designed to produce a structured trade-off analysis between orchestration-based and choreography-based saga patterns for distributed transaction coordination. The template uses square-bracket placeholders that you must replace with your specific context before execution. The output is designed to be a decision memo that can be directly fed into an Architecture Decision Record (ADR) or a technical design review document. The prompt forces the model to compare the two patterns across dimensions that matter in production—visibility, coupling, failure recovery, testing difficulty, and team autonomy—rather than producing a generic textbook comparison.

textCopy
You are a distributed systems architect evaluating saga coordination patterns for a specific business workflow. Your task is to produce a structured comparison between orchestration-based and choreography-based sagas.

## WORKFLOW CONTEXT
[WORKFLOW_DESCRIPTION: Describe the business transaction that spans multiple services. Include the sequence of steps, the services involved, and the compensating actions required on failure.]

## SYSTEM CONSTRAINTS
[CONSTRAINTS: List operational constraints such as latency budgets, throughput requirements, team topology, existing infrastructure, regulatory requirements, and observability tooling.]

## COMPARISON DIMENSIONS
For each dimension below, analyze both patterns and state which pattern is stronger for this specific workflow. Provide concrete reasoning tied to the workflow context, not generic definitions.

1. **Visibility and Monitoring**: How easy is it to know the current state of a saga? Can you answer "where is order #12345 right now?" without querying multiple services?
2. **Coupling and Service Autonomy**: How much do services need to know about each other? What happens when a new service joins or leaves the workflow?
3. **Failure Recovery**: How are partial failures detected? How are compensating transactions triggered? What happens if the coordinator or a participant crashes mid-saga?
4. **Testing and Debugging**: Can you test the saga end-to-end in a development environment? How do you reproduce a failure that occurred in production?
5. **Team Autonomy and Ownership**: Can a single team own the entire saga? How do multiple teams coordinate changes to the workflow?
6. **Temporal Coupling**: Are there hidden assumptions about execution order, timing, or synchronous responses that could cause cascading failures under load?

## OUTPUT FORMAT
Return a JSON object with the following structure:
{
  "workflow_summary": "One-sentence summary of the workflow",
  "recommendation": "orchestration" | "choreography" | "hybrid",
  "confidence": "high" | "medium" | "low",
  "dimension_analysis": [
    {
      "dimension": "string",
      "orchestration_assessment": "string",
      "choreography_assessment": "string",
      "winner_for_this_workflow": "orchestration" | "choreography" | "tie",
      "rationale": "string tied to the workflow context"
    }
  ],
  "failure_modes": [
    {
      "scenario": "string describing a specific failure",
      "orchestration_behavior": "string",
      "choreography_behavior": "string",
      "unresolved_risk": "string or null"
    }
  ],
  "implementation_risks": ["risk 1", "risk 2"],
  "decision_triggers": {
    "choose_orchestration_if": ["condition 1", "condition 2"],
    "choose_choreography_if": ["condition 1", "condition 2"],
    "choose_hybrid_if": ["condition 1", "condition 2"]
  },
  "open_questions": ["question that needs answering before final decision"]
}

## CONSTRAINTS
- Do not recommend a pattern without tying the reasoning to the specific workflow context provided.
- If the workflow description is insufficient to analyze a dimension, mark that dimension's confidence as "low" and add an open question.
- For each failure mode, identify whether the risk is resolved, mitigated, or unresolved for each pattern.
- If a hybrid approach is recommended, specify exactly which steps use orchestration and which use choreography.
- Flag any hidden temporal coupling risks explicitly in the failure_modes array.

To adapt this template, replace the [WORKFLOW_DESCRIPTION] and [CONSTRAINTS] placeholders with your specific context. The workflow description should be detailed enough that someone unfamiliar with your system can understand the sequence of steps, the services involved, and what must happen on failure. Vague descriptions produce vague comparisons. The constraints section is where you inject operational reality—latency budgets, team structures, existing infrastructure, and regulatory requirements all tilt the analysis toward one pattern or the other. If you need to add additional comparison dimensions specific to your domain, insert them into the numbered list before dimension 6. Do not remove the output format schema; it is designed to produce machine-readable output that can be validated before the analysis enters your decision record. After generating the analysis, validate that every rationale field references the workflow context explicitly—generic answers indicate the model is pattern-matching rather than reasoning about your specific case.

This prompt is designed to be integrated into an architecture decision workflow, not used as a one-off chat. The primary integration point is a design review tool or a CI/CD pipeline gate that triggers when a new Architecture Decision Record (ADR) or saga design proposal is submitted. The application should pre-populate the [SAGA_CONTEXT] with structured data from the proposal—extracted service boundaries, proposed events, and compensating transactions—rather than relying on the user to paste freeform text. This ensures the model receives consistent, machine-readable context that reduces hallucination risk.

The implementation harness should wrap the prompt in a validation and retry loop. After the model returns the comparison table and analysis, a post-processing validator must check that: (1) all required dimensions (visibility, coupling, failure recovery, testing difficulty, team autonomy) are present in the output, (2) the recommendation section explicitly maps to the provided [CONSTRAINTS] like latency budgets or team topology, and (3) the hidden temporal coupling check has been executed and its results are non-empty. If validation fails, the harness should retry with the same prompt and an appended error message specifying which check failed, up to a maximum of three attempts. For high-risk financial or healthcare systems, the output must be routed to a human review queue before being committed to the ADR repository. Log the raw prompt, model response, validator results, and reviewer decision for auditability.

Model choice matters here. Use a model with strong reasoning capabilities and a large context window, such as Claude 3.5 Sonnet or GPT-4o, because the prompt requires holding multiple architectural dimensions and constraints in memory simultaneously. Avoid small or fast models that may drop dimensions or skip the temporal coupling analysis. If your organization uses a local or private deployment, ensure the model has been evaluated on structured comparison tasks before wiring it into this harness. The next step is to build the eval dataset using the failure modes described in the Testing and Evaluation section, then deploy the harness in shadow mode against historical ADRs to calibrate retry thresholds before enabling it as a blocking review gate.