Batch vs Stream Processing Architecture Prompt Template

This prompt is for data engineers and platform architects who need a structured comparison between batch and stream processing for a specific workload. Use it when the team is debating processing paradigms and needs a decision memo that surfaces trade-offs across latency, fault tolerance, operational complexity, cost, and correctness guarantees. The prompt forces explicit consideration of late-arriving data, reprocessing requirements, and failure recovery patterns that are often overlooked in advocacy-driven debates.

The ideal user brings a concrete workload description, not a hypothetical preference. Required context includes the data source characteristics (volume, velocity, schema), the downstream consumer's latency tolerance, the acceptable data staleness window, and the team's operational maturity for managing distributed systems. Without this context, the model will produce a generic textbook comparison that fails to resolve the actual architectural debate. The prompt is most effective when the team has already identified two or three candidate architectures and needs a rigorous, dimension-by-dimension trade-off analysis rather than a starting-point recommendation.

Do not use this prompt when the workload is trivially one paradigm—for example, a nightly report on static data clearly belongs in batch, while real-time fraud detection with sub-second requirements clearly belongs in stream processing. Do not use it when the team has already committed to a platform that dictates the choice, such as an existing Kafka ecosystem that makes stream processing the default, or a legacy data warehouse that only supports batch ingestion. In those cases, the decision is already constrained, and the prompt will generate analysis that cannot be acted upon. Also avoid this prompt for purely educational or theoretical debates where no real workload exists; the output quality depends on concrete constraints that only a real system provides.

This prompt template is designed to produce a rigorous, dimension-by-dimension comparison between batch and stream processing approaches for a specific data workload. It forces the model to consider not just latency and throughput, but also fault tolerance semantics, operational complexity, cost profiles, and correctness guarantees. Copy the template below into your AI harness, replace the square-bracket placeholders with concrete values, and iterate on the constraints until the output reliably surfaces the non-obvious trade-offs that matter for your system.

codeCopy
You are a senior data infrastructure architect evaluating processing paradigms. Your task is to produce a structured trade-off analysis comparing batch and stream processing for the workload described below. Be precise, cite specific failure modes, and avoid generic advice.

## WORKLOAD DESCRIPTION
[WORKLOAD_DESCRIPTION]

## CONSTRAINTS
- Latency budget: [MAX_ACCEPTABLE_LATENCY]
- Data volume: [DAILY_DATA_VOLUME]
- Correctness requirement: [EXACTLY_ONCE | AT_LEAST_ONCE | BEST_EFFORT]
- Team size and expertise: [TEAM_SIZE_AND_SKILLS]
- Existing infrastructure: [EXISTING_INFRASTRUCTURE]
- Budget constraints: [BUDGET_CONSTRAINTS]

## COMPARISON DIMENSIONS
For each dimension below, provide a concrete comparison with specific examples from the workload description. Do not use generic statements.

1. **Latency and Freshness**: Compare end-to-end latency from data arrival to queryable result. Include worst-case scenarios.
2. **Fault Tolerance and Correctness**: Compare behavior under node failure, network partition, and crash recovery. Address exactly-once semantics, duplicate handling, and late-arriving data.
3. **Operational Complexity**: Compare deployment, monitoring, debugging, and on-call burden. Include specific operational failure modes for each paradigm.
4. **Cost Profile**: Compare infrastructure cost, engineering time, and opportunity cost. Include idle resource waste for batch and over-provisioning risk for streaming.
5. **Reprocessing and Backfill**: Compare the difficulty and cost of reprocessing historical data, fixing bugs in output, and handling schema changes.
6. **Scalability and Throughput**: Compare scaling behavior under load spikes, backpressure handling, and throughput ceilings.

## OUTPUT FORMAT
Return a JSON object with this exact structure:
{
  "recommendation": "BATCH" | "STREAM" | "HYBRID",
  "confidence": "HIGH" | "MEDIUM" | "LOW",
  "summary": "One-paragraph summary of the primary trade-off driving the recommendation.",
  "comparison_matrix": [
    {
      "dimension": "string",
      "batch_assessment": "string",
      "stream_assessment": "string",
      "winner": "BATCH" | "STREAM" | "TIE",
      "decisive_factor": "string explaining why this dimension matters for this specific workload"
    }
  ],
  "failure_modes": [
    {
      "scenario": "string describing a specific failure scenario",
      "batch_behavior": "string",
      "stream_behavior": "string",
      "recommended_mitigation": "string"
    }
  ],
  "risks_and_unknowns": ["list of assumptions that could invalidate the recommendation"],
  "next_steps": ["concrete actions to validate the recommendation before committing"]
}

## RULES
- If the latency budget is under 1 second, stream processing must be the default unless strong counter-evidence exists.
- If exactly-once correctness is required and the team has no streaming experience, flag this as a high-risk combination.
- If late-arriving data is a known problem, explicitly address reprocessing complexity in both paradigms.
- Do not recommend hybrid architectures without specifying which parts are batch and which are stream, and why.

After copying the template, replace each bracketed placeholder with concrete values from your workload. The [WORKLOAD_DESCRIPTION] should be detailed enough that someone unfamiliar with your system could reason about it—include data sources, downstream consumers, peak loads, and any regulatory or compliance requirements. The [EXISTING_INFRASTRUCTURE] field is critical because it constrains what's realistic; a theoretically superior architecture that requires a platform migration your team can't execute in six months is not a valid recommendation. Run the prompt with at least three distinct workload profiles (normal load, peak load, failure scenario) to test whether the model's reasoning remains consistent or flips based on edge cases. If the output contains generic statements like "streaming is more complex" without specifics, tighten the constraints or add examples of unacceptable generic output to the prompt.

This prompt is designed to be called from an architecture review tool, a decision-record generator, or an internal platform that assists engineering teams with structured trade-off analysis. The caller must supply the required inputs—[PROCESSING_REQUIREMENTS], [LATENCY_BUDGET], [DATA_VOLUME], [FAULT_TOLERANCE_NEEDS], [OPERATIONAL_CONSTRAINTS], and [TEAM_CAPABILITY]—as a structured JSON object or a formatted markdown block. The model should be instructed to return a valid JSON object matching the [OUTPUT_SCHEMA] defined in the prompt template, which includes a dimension-by-dimension comparison matrix, a recommendation with confidence level, and a list of identified risks.

Wire the prompt into an application by first validating all input fields before sending the request. Check that latency budgets are numeric, data volumes include units, and team capability fields are populated. After receiving the model response, run a structural validation pass: confirm the output is parseable JSON, the comparison matrix contains all required dimensions (latency, fault tolerance, operational complexity, cost, correctness guarantees), and the recommendation field is present. If validation fails, retry once with the same inputs and an added [CONSTRAINTS] note flagging the specific validation error. If the second attempt also fails, escalate to a human reviewer queue with the original inputs and both failed outputs attached. For high-risk processing decisions—such as those involving financial transactions, healthcare data, or safety-critical systems—always require human approval before the recommendation is accepted, regardless of model confidence.

Log every request and response pair, including the model version, input hash, output schema compliance status, and whether human review was triggered. This audit trail supports future prompt regression testing and helps identify patterns in failure modes. Common production failure modes include the model recommending stream processing without addressing late-arriving data handling, ignoring reprocessing requirements for batch, or failing to flag that the team lacks operational experience with the recommended paradigm. Build eval assertions that specifically check for these gaps: assert that late-data strategies are mentioned when stream processing is recommended, assert that reprocessing plans appear when batch is recommended, and assert that team capability gaps are explicitly flagged in the risks array. When integrating with a decision-record system, map the validated output fields directly to your ADR template so the comparison matrix becomes the 'Options Considered' section and the risks become 'Consequences'.

For model choice, use a model with strong reasoning capabilities and JSON mode support. Avoid models that struggle with structured output or multi-dimensional comparison tasks. If your platform supports tool use, consider exposing a schema-validation tool that the model can call to self-check its output before returning it, reducing the need for post-hoc validation retries. Do not use this prompt for real-time production path selection where milliseconds matter—this is a design-time decision tool, not a runtime router. The next step after generating the analysis is to socialize it with the team, update the decision log, and schedule a follow-up review once the chosen paradigm has been in production for a defined evaluation period.