Concurrent Cache Invalidation Conflict Prompt

This prompt is designed for infrastructure engineers and SREs who operate distributed caching layers where multiple writers or automated processes can issue contradictory invalidation commands for the same cache key within a short time window. The job-to-be-done is resolving a set of conflicting signals—such as stale, refresh, and delete—into a single, safe cache-update decision that preserves data consistency and avoids unnecessary cache churn. The ideal user is someone integrating this prompt into a cache-management agent, a reconciliation loop, or an operational runbook that triggers when a conflict detector flags a key with multiple pending invalidation events.

To use this prompt effectively, you must provide a structured conflict log containing the cache key, a timestamped history of invalidation signals, and any relevant metadata such as the source of each signal (e.g., a database writer, a TTL eviction policy, or an application-level cache-busting call). The prompt assumes that conflict detection has already occurred upstream and that the log represents a bounded window of concurrent events. It does not handle cache-warming strategies, TTL policy design, or initial cache-population logic. The output is a decision object specifying the action to take (delete, refresh, no-op) and a concise explanation grounded in the provided signal history, which you can feed directly into your cache-invalidation executor.

Do not use this prompt when the conflict involves keys that span multiple cache clusters with independent consistency models, as the prompt lacks the distributed consensus logic required for cross-cluster coordination. It is also unsuitable for real-time bidding or sub-millisecond decision loops where the latency of an LLM call would violate your SLO. For high-risk deployments where an incorrect invalidation could cause data corruption or financial loss, always pair this prompt with a post-decision validation step—such as comparing the resolved action against a deterministic rule-based fallback—and log every decision for auditability. If the conflict log contains more than a handful of signals or spans a time window exceeding your cache's typical reconciliation threshold, consider whether a simpler, rule-based merge (e.g., 'delete wins over refresh') would be safer and cheaper than invoking an LLM.

This template is the core instruction set you send to the model when your cache-coordination harness detects concurrent invalidation signals (stale, refresh, delete) for the same cache key. The prompt forces the model to reason about the temporal order, signal priority, and the current cache state before producing a single safe update decision. It is designed to be wrapped in a retry loop with strict output validation.

textCopy
You are a cache-invalidation conflict resolver for a distributed system. Your job is to examine a set of concurrent invalidation signals that arrived for the same cache key and produce a single, safe cache-update decision.

## INPUT
- Cache Key: [CACHE_KEY]
- Current Cache State: [CURRENT_STATE]
- Conflicting Signals (ordered by arrival timestamp):
[SIGNALS_ARRAY]

## SIGNAL TYPES
- `STALE`: The data source has newer data. The cache entry should be refreshed.
- `REFRESH`: A specific new value is provided. The cache entry should be updated to this value.
- `DELETE`: The underlying data was removed. The cache entry should be invalidated.

## CONSTRAINTS
- You must output exactly one decision.
- A `DELETE` signal that arrived after a `STALE` or `REFRESH` signal for the same key must win, because the data no longer exists at the source.
- If multiple `REFRESH` signals conflict, prefer the one with the latest source timestamp. If timestamps are equal, prefer the signal with the highest `priority` field.
- If a `STALE` signal arrives after a `REFRESH` signal with a newer source timestamp, the `REFRESH` wins.
- Never produce a decision that would write data known to be deleted.
- If the current cache state is `NULL` and the winning signal is `STALE`, output `NOOP`.

## OUTPUT SCHEMA
Return ONLY a valid JSON object with no additional text:
{
  "decision": "REFRESH" | "DELETE" | "NOOP",
  "winning_signal_id": "string | null",
  "reasoning": "A concise explanation referencing signal timestamps and the conflict-resolution rule applied.",
  "cache_key": "[CACHE_KEY]"
}

## EXAMPLES
Input Signals:
1. {id: "s1", type: "STALE", timestamp: 100}
2. {id: "s2", type: "REFRESH", value: "v2", source_timestamp: 105, priority: 1, timestamp: 101}
Current State: {value: "v1", source_timestamp: 90}
Output: {"decision": "REFRESH", "winning_signal_id": "s2", "reasoning": "REFRESH signal s2 has a newer source_timestamp (105) than the STALE signal s1 (100) and the current state (90).", "cache_key": "user:123:profile"}

Input Signals:
1. {id: "s3", type: "STALE", timestamp: 200}
2. {id: "s4", type: "DELETE", timestamp: 201}
Current State: {value: "v3", source_timestamp: 150}
Output: {"decision": "DELETE", "winning_signal_id": "s4", "reasoning": "DELETE signal s4 arrived after STALE signal s3. DELETE always wins.", "cache_key": "user:123:profile"}

## RISK LEVEL
[HIGH]. An incorrect decision can cause stale reads, data loss, or cache poisoning. Validate the output JSON strictly before applying the decision.

Before wiring this into production, replace every square-bracket placeholder with real values from your cache-coordination harness. The [SIGNALS_ARRAY] must be a serialized JSON array of signal objects, each containing at minimum id, type, and timestamp. For REFRESH signals, include value, source_timestamp, and priority. The [CURRENT_STATE] should be the existing cache entry or null. After receiving the model's output, validate the JSON against the schema, check that cache_key matches the input key, and verify that the decision does not violate any of the stated constraints before applying it to your cache. For high-risk deployments, log every decision alongside the input signals for auditability.

This prompt is designed to sit inside a cache-coordination service that receives conflicting invalidation signals—stale, refresh, delete—arriving concurrently for the same key. The harness should invoke the model only when the service detects a conflict that cannot be resolved deterministically by timestamp ordering or CRDT merge rules alone. Before calling the model, the harness must assemble a structured input containing the key, the conflicting operations with their timestamps and origin services, the current cached value, and any relevant TTL or dependency metadata. The model's output is a single safe cache-update decision, which the harness then executes and logs.

Validation and execution guardrails: The harness must validate the model's output against a strict schema before acting on it. The decision must be one of three allowed actions: keep, delete, or refresh. If the model returns refresh, the harness must verify that a valid refresh_source field is present and reachable. The harness should also enforce a safety timeout: if the model does not return a valid decision within 500ms, fall back to a deterministic rule (e.g., keep existing value and log the conflict for async resolution). All model decisions must be logged with the input context, model version, and decision for auditability. For high-throughput caches, consider batching multiple conflict keys into a single model call with an array input to reduce latency overhead.

Retry and escalation logic: If the model returns an invalid decision or the validation layer rejects the output, the harness should retry once with the same input plus the validation error message appended as [VALIDATION_ERROR]. If the second attempt also fails, the harness must not retry further—instead, it should execute the deterministic fallback, log the failure, and increment a metric for model-decision failures. For caches serving user-facing traffic where a wrong invalidation could cause stale data exposure, the harness should route refresh decisions through a human-review queue if the key is tagged as high-risk (e.g., authentication tokens, pricing data, or compliance-relevant records).

Model choice and deployment: This prompt works best with models that have strong instruction-following and structured-output capabilities (e.g., GPT-4o, Claude 3.5 Sonnet). Avoid smaller or older models that may hallucinate action values or ignore the output schema. Deploy the prompt behind a lightweight API endpoint that your cache-coordination service can call synchronously. Cache the prompt template itself and use prompt-caching features if available to reduce latency on repeated calls. Monitor decision latency, validation-failure rate, and fallback-trigger rate as primary health metrics. If the fallback rate exceeds 1%, investigate whether the conflict patterns have shifted and the prompt needs updated examples.