Strong vs Eventual Consistency Trade-Off Prompt Template

This prompt is for distributed systems engineers and architects who are actively debating consistency guarantees for a specific system context. Use it when the team is designing a new service, evaluating a data store migration, or resolving a disagreement about whether strong or eventual consistency is the right fit. The prompt forces the model to reason across four concrete dimensions—correctness guarantees, availability during partitions, latency impact, and application-level compensation complexity—and produce a decision memo that can be shared with the team. It assumes the reader already understands CAP theorem and the basics of consistency models; it does not explain them.

Do not use this prompt as a general database comparison tool or to generate educational content about consistency. It is not designed for comparing specific products like DynamoDB versus Spanner, nor for generating tutorial material for junior engineers. The prompt is most effective when you provide a concrete system description, including the data operations in question, the read and write patterns, the latency budget, the partition tolerance requirements, and any existing compensation logic. Without this context, the model will produce a generic analysis that adds little value. For high-stakes decisions involving financial correctness, safety-critical systems, or regulatory compliance, always route the output through human review and ground claims against your actual system invariants.

The output is a decision memo, not a tie-breaking vote. It will surface trade-offs that the team may have overlooked, such as unstated invariants that would break under eventual consistency or compensation paths that introduce more complexity than the team estimated. After receiving the output, validate the identified invariants against your actual codebase and run the eval criteria provided in the playbook to check for missing failure modes. If the model flags a compensation path you haven't designed, treat that as a prompt to do the design work, not as a reason to accept or reject a consistency model outright.

This prompt template is designed to produce a rigorous, dimension-by-dimension comparison of strong and eventual consistency for a specific system or use case. It forces the model to move beyond generic definitions and apply the trade-offs to your concrete context, including invariants, failure modes, and compensation complexity. Copy the block below into your AI harness, replace the square-bracket placeholders with your specific details, and run it as part of an architecture decision record (ADR) or design review workflow.

markdownCopy
You are a principal distributed systems engineer. Your task is to produce a structured, evidence-based trade-off analysis comparing **strong consistency** and **eventual consistency** for the system described below. Do not advocate for a pre-determined answer. Your analysis must surface hidden costs, failure modes, and application-level complexity.

## System Context
[SYSTEM_DESCRIPTION: Describe the system, its primary function, and its users.]

## Specific Operation Under Review
[OPERATION: Describe the specific read or write operation being analyzed, e.g., 'A user updates their profile email address, which is then used for login and notifications.']

## Key Requirements
[REQUIREMENTS: List critical business or technical requirements, such as latency budgets, throughput targets, regulatory constraints, or user experience expectations.]

## Analysis Dimensions
For each dimension below, provide a direct comparison of how strong consistency and eventual consistency models would behave, including concrete consequences for this specific operation.

1.  **Correctness Guarantees**: What invariants are guaranteed? What anomalies (e.g., stale reads, lost updates, dirty reads) are possible under each model for this operation?
2.  **Availability During Partitions**: How does each model behave during a network partition (CAP theorem implications)? What is the blast radius of an unavailability event?
3.  **Latency and Throughput Impact**: Compare the expected read/write latency and overall system throughput. Quantify the impact of coordination protocols (e.g., 2PC, Paxos) or conflict resolution (e.g., CRDTs, last-writer-wins).
4.  **Application-Level Compensation Complexity**: If eventual consistency is chosen, what compensating transactions, reconciliation workflows, or user-facing error messages must be built? Estimate the engineering effort.
5.  **Operational Complexity**: Compare the debugging, monitoring, and testing difficulty. How do you verify correctness in production for each model?
6.  **Data Integrity and Conflict Resolution**: How are conflicts detected and resolved? What is the risk of permanent data corruption or user-visible inconsistency?

## Output Format
Return your analysis as a JSON object with the following structure. Do not include any text outside the JSON.
{
  "summary": "A one-paragraph executive summary of the primary trade-off for this specific operation.",
  "strong_consistency_analysis": {
    "correctness": "...",
    "availability_during_partition": "...",
    "latency_throughput": "...",
    "compensation_complexity": "N/A - Not applicable",
    "operational_complexity": "...",
    "data_integrity": "..."
  },
  "eventual_consistency_analysis": {
    "correctness": "...",
    "availability_during_partition": "...",
    "latency_throughput": "...",
    "compensation_complexity": "...",
    "operational_complexity": "...",
    "data_integrity": "..."
  },
  "unstated_invariants": [
    "List any business or data invariants implied by the requirements that were not explicitly stated but would be violated by one of the models."
  ],
  "recommendation": "A final recommendation for this specific operation, justified by the analysis above. If the choice is not clear-cut, state the conditions under which you would choose each model.",
  "required_safeguards": [
    "List concrete safeguards, tests, or monitors required if the recommended model is adopted."
  ]
}

## Constraints
- Ground every claim in the specific operation and requirements provided.
- If a dimension is irrelevant, state why instead of omitting it.
- Flag any catastrophic failure mode (e.g., silent data loss, unrecoverable inconsistency) prominently.

After copying the template, the most critical step is filling in the [SYSTEM_DESCRIPTION] and [OPERATION] placeholders with extreme precision. A vague description like 'an e-commerce checkout' will yield a generic, low-value analysis. Instead, specify the exact data being mutated, the actors involved, and the downstream read paths. For example: 'When a customer places an order, the inventory service decrements stock for SKU-123. This stock level is read by the checkout service to prevent overselling and by the warehouse dashboard for picking.' This level of detail allows the model to reason about specific conflict scenarios and compensation logic. The [REQUIREMENTS] field should include measurable targets like 'p99 write latency < 50ms' or 'zero tolerance for overselling,' as these directly constrain the trade-off space.

Before integrating this prompt into a product workflow, you must validate the output against the defined JSON schema. A malformed JSON response will break any downstream automation. Implement a retry mechanism with the validation error message fed back to the model for self-correction. For high-stakes decisions, the generated analysis is a starting point for a human architecture review, not the final word. The unstated_invariants field is a key evaluation criterion; a strong analysis will surface hidden business rules that the initial requirements missed. If the model fails to identify any unstated invariants, treat the output with increased skepticism and re-prompt with a more detailed system description.

This prompt is designed to be integrated into an Architecture Decision Record (ADR) pipeline or a design review bot. The primary integration point is a function that accepts a structured [SYSTEM_CONTEXT] object—describing the data operations, user expectations, and infrastructure—and returns a structured trade-off analysis. Do not treat this as a free-form chat prompt; the value comes from enforcing the [OUTPUT_SCHEMA] so that downstream systems can render a comparison matrix, flag unstated invariants, and attach the analysis to a decision log. The model should be called with a low temperature (e.g., 0.1–0.2) to maximize deterministic, analytical output rather than creative prose.

Input Validation: Before calling the model, validate that [SYSTEM_CONTEXT] contains concrete data operations (e.g., 'shopping cart checkout', 'inventory reservation'), not just abstract nouns. If the context is too vague, reject the request and ask the user to describe at least one read-modify-write cycle. Model Selection: Use a model with strong reasoning capabilities. GPT-4o or Claude 3.5 Sonnet are appropriate. Avoid smaller or older models that may collapse the nuanced trade-off dimensions into generic advice. Retry Logic: If the output fails JSON schema validation or the eval_checks block reports a confidence score below a defined threshold (e.g., 0.7), implement a single retry with the validation errors appended to the prompt as a [CORRECTION_FEEDBACK] block. Do not loop indefinitely; after two failures, surface the incomplete analysis to a human reviewer with the errors flagged.

Tool Integration: For teams using a decision log (e.g., a markdown file in a repository or a structured database), wire the validated JSON output to a tool that formats it into an ADR. The comparison_matrix can be rendered as a table, and the unstated_invariants list should be appended as a dedicated 'Risks and Assumptions' section. Human Review Gate: Because consistency model choices directly impact data correctness and revenue, always require a human to approve the analysis before it is committed as a decision. The approval step should highlight any invariant that was flagged as 'unstated' or 'assumed' by the model, as these represent the highest risk of production incidents. Logging: Log the full prompt, the raw model response, the parsed JSON, and the human reviewer's decision. This audit trail is critical for post-incident review to understand why a specific consistency guarantee was chosen.