Multi-Region Write Conflict Resolution Load Scenario Prompt

This prompt is for a distributed systems engineer or performance architect who needs to design a load test that specifically stresses the conflict resolution mechanisms of a geo-replicated data store. The job-to-be-done is not general performance testing; it is to generate a precise, executable scenario that isolates write conflicts across regions, projects realistic conflict rates, and defines the criteria for validating that the system's resolution strategy (e.g., last-writer-wins, CRDTs, custom merge logic) behaves correctly under load. The required context includes the database topology, replication protocol, conflict resolution strategy, and target write throughput per region.

Use this prompt when you are preparing for a game-day exercise, validating a new anti-entropy repair process, or certifying a multi-region deployment before production traffic is geo-distributed. It is appropriate when you have a known conflict resolution strategy and need to generate a test that produces measurable conflict rates, not just high write volumes. The output should be used by a performance engineer to script a test in a tool like k6, Locust, or a custom harness, and by an observability engineer to configure the dashboards that will detect consistency anomalies during the run.

Do not use this prompt for a simple single-region write throughput test, for testing read-only replicas, or for evaluating network latency in isolation. It is also unsuitable if you lack a clear specification of the conflict resolution strategy, as the prompt requires this to generate valid assertions. If your goal is to test failover speed or node recovery time without write conflicts, choose a dedicated failover or resilience prompt instead. After generating the scenario, you must validate the clock skew assumptions and anti-entropy repair impact with your infrastructure team before execution, as these are the most common sources of false-positive test results.

This prompt template is designed to be copied directly into your AI harness or testing pipeline. It forces the model to produce a concrete, executable load scenario by requiring specific inputs about your geo-distributed topology, conflict resolution mechanism, and consistency requirements. The square-bracket placeholders must be replaced with your system's actual parameters before execution. Do not leave any placeholder unresolved, as the model will hallucinate reasonable but incorrect defaults for your environment.

textCopy
You are a distributed systems performance engineer designing a load test scenario for a multi-region, geo-replicated data store.

Generate a detailed write conflict resolution load scenario using the inputs below. The scenario must be executable by a load testing framework and must include specific assertions for correctness under conflict.

## REQUIRED INPUTS
- **Topology**: [TOPOLOGY_DESCRIPTION]
- **Conflict Resolution Strategy**: [CONFLICT_RESOLUTION_STRATEGY]
- **Consistency Model**: [CONSISTENCY_MODEL]
- **Write Throughput Target (per region)**: [WRITE_THROUGHPUT_TARGET]
- **Conflict Rate Projection**: [CONFLICT_RATE_PROJECTION]
- **Anti-Entropy Repair Mechanism**: [ANTI_ENTROPY_REPAIR_MECHANISM]
- **Clock Skew Assumption (max ms)**: [CLOCK_SKEW_ASSUMPTION]
- **SLA Targets**: [SLA_TARGETS]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "scenario_name": "string",
  "topology_summary": "string",
  "workload_profile": {
    "regions": [
      {
        "region_id": "string",
        "write_rate_rps": "number",
        "read_rate_rps": "number",
        "key_distribution": "string",
        "key_hotspot_percentage": "number"
      }
    ],
    "conflict_injection": {
      "conflicting_key_set_size": "number",
      "write_interleaving_pattern": "string",
      "expected_conflict_rate": "number"
    }
  },
  "resolution_validation": {
    "strategy_under_test": "string",
    "correctness_assertions": ["string"],
    "anomaly_detection_criteria": ["string"]
  },
  "consistency_checks": {
    "monotonicity_check": "string",
    "read_your_writes_check": "string",
    "causal_consistency_check": "string",
    "anti_entropy_repair_impact": "string"
  },
  "clock_skew_mitigations": ["string"],
  "failure_modes_to_monitor": ["string"],
  "abort_conditions": ["string"]
}

## CONSTRAINTS
- The scenario must test exactly one conflict resolution strategy at a time.
- Include at least three correctness assertions that can be validated post-test.
- Anomaly detection criteria must be specific and measurable (e.g., "stale read count > 0 for keys written within 500ms").
- Clock skew mitigations must reference the provided max skew assumption.
- If the anti-entropy repair mechanism is asynchronous, include its expected impact on consistency checks.
- Abort conditions must include both safety thresholds (e.g., data corruption detected) and confidence thresholds (e.g., conflict rate exceeds projection by 2x).

## RISK LEVEL
[RISK_LEVEL]

If RISK_LEVEL is "high" or "critical", add a "human_review_required" boolean field to the output and set it to true. Include a "review_notes" field explaining which assertions require manual validation before test execution.

Adaptation guidance: Replace each placeholder with concrete values from your system's architecture and test plan. The [TOPOLOGY_DESCRIPTION] should include region names, replication topology (e.g., multi-leader, leaderless), and network latency assumptions. The [CONFLICT_RESOLUTION_STRATEGY] must name a specific strategy (e.g., LWW, CRDT, custom merge function) rather than a generic description. If your system does not have an anti-entropy repair mechanism, set [ANTI_ENTROPY_REPAIR_MECHANISM] to "none" and expect the model to flag missing repair impact in the output. The [RISK_LEVEL] placeholder accepts "low", "medium", "high", or "critical" and gates whether the output includes human review requirements. Before running the generated scenario in production-like environments, validate that the correctness assertions align with your conflict resolution implementation and that the abort conditions will trigger before any data corruption can propagate across regions.

This prompt is designed to be called programmatically as part of a load test design pipeline, not as a one-off chat interaction. The primary integration point is a test planning service that accepts system architecture metadata, replication topology details, and conflict resolution strategy parameters, then invokes the LLM to produce a structured scenario definition. The output should be parsed as a JSON object containing load profiles per region, conflict rate projections, resolution strategy validation steps, and anomaly detection criteria. This structured output can then be consumed by load generation tools like k6, Locust, or custom chaos experiment runners to configure region-specific virtual user groups and failure injection schedules.

Validation and Schema Enforcement: Before executing the generated scenario, validate the output against a strict schema. Required fields include regions (array of region objects with write_rate_rps, read_rate_rps, latency_ms_to_peer), conflict_rate_projection (object with expected_conflict_pct, confidence_interval, assumptions), resolution_strategy_under_test (string enum: last-write-wins, custom-merge, crdt, quorum-based), and anomaly_detection_checks (array of check objects with metric, threshold, evaluation_window_sec). Reject any output missing these fields or containing values outside expected ranges (e.g., negative write rates, conflict percentages >100). Log validation failures with the raw LLM response for debugging prompt drift. For high-stakes production systems, route the validated scenario to a human performance engineer for approval before execution, especially when the scenario includes destructive failure injections like partition or clock skew tests.

Retry and Fallback Logic: If the LLM response fails schema validation, implement a single retry with an augmented prompt that includes the validation error message and the specific field that failed. For example: The previous output was rejected because 'conflict_rate_projection.expected_conflict_pct' was outside the 0-100 range. Please regenerate the scenario with a corrected value. If the retry also fails, fall back to a deterministic template-based scenario generator that uses the same input parameters but produces a simpler, less nuanced load profile. Log the fallback event and the validation errors for prompt improvement cycles. Do not silently execute a partially valid scenario.

Model Choice and Tool Integration: Use a model with strong structured output capabilities and a large context window, such as Claude 3.5 Sonnet or GPT-4o, because the prompt requires reasoning over multi-region topologies, consistency models, and failure mode interactions. Enable JSON mode or structured output features if available. Wire the prompt into a tool chain where the LLM has access to a get_region_topology function that returns actual latency measurements and replication configuration from your observability platform, rather than relying solely on static input parameters. This grounds the scenario in real infrastructure data. For RAG integration, retrieve your organization's internal runbooks on conflict resolution procedures and anti-entropy repair schedules so the prompt can reference actual operational practices rather than generic best practices.

Observability and Traceability: Tag every generated scenario with a unique scenario_id, the prompt version hash, input parameter snapshot, and model identifier. Store these alongside the validated output in your test artifact repository. After executing the load test, compare actual conflict rates, anomaly detections, and resolution latencies against the prompt's projections. Feed significant deviations back into the prompt as few-shot examples or context for future scenario generation runs. This closes the loop between prediction and observation, improving scenario accuracy over time. Avoid running this prompt in production pipelines without first testing it against a golden dataset of known multi-region failure modes to calibrate its conflict rate projections and anomaly detection sensitivity.