Horizontal vs Vertical Scaling Strategy Prompt Template

This prompt is for Site Reliability Engineers, capacity planners, and cloud architects who need to move beyond intuition when choosing between horizontal and vertical scaling for a specific workload. The job-to-be-done is a neutral, multi-dimensional trade-off analysis that compares cost efficiency, operational simplicity, availability impact, and workload suitability. Use it during architecture reviews, capacity planning cycles, or pre-commitment design discussions where advocacy for a familiar pattern can mask single-point-of-failure blind spots. The prompt forces the model to act as a neutral infrastructure analyst, not an advocate for either approach.

The required context is a concrete workload description, including its resource profile (CPU/memory/IO), statefulness, traffic patterns, and current or proposed instance topology. Without this specificity, the analysis will be generic and useless for decision-making. Do not use this prompt for real-time incident response where a runbook must be executed immediately; it is a planning tool, not a remediation script. It is also not a substitute for load testing or benchmarking—use it to structure the decision framework before empirical validation, not to replace it. The output is most valuable when the team has a genuine choice between scaling strategies and needs to surface hidden assumptions about failure domains, operational toil, and cost-at-scale.

After generating the analysis, validate the output against your actual workload constraints. Check that the model has correctly identified stateful components that would break under horizontal scaling, and that its cost projections account for your specific pricing model (reserved instances, spot, enterprise agreements). The next step is to take the surfaced trade-offs into a design review or decision memo, not to treat the AI output as the final decision. Avoid using this prompt when the scaling path is already locked by organizational policy or when the workload has hard technical constraints that make one option non-viable—the analysis will waste time on a foregone conclusion.

The prompt below is designed to be copied directly into your AI harness. It forces a structured comparison across dimensions critical to capacity planning: cost efficiency, operational simplicity, availability impact, and workload suitability. Before using it, you must replace every [SQUARE_BRACKET] placeholder with concrete data from your system context. The prompt is designed to produce a decision memo, not just a pros-and-cons list, making it suitable for architecture decision records (ADRs).

textCopy
You are a senior site reliability engineer evaluating scaling strategies for a production service. Your task is to produce a structured trade-off analysis comparing horizontal scaling (adding more instances) and vertical scaling (increasing instance size) for the given workload.

## Input Context
- Current System Description: [SYSTEM_DESCRIPTION]
- Workload Characteristics: [WORKLOAD_CHARACTERISTICS]
- Current Bottleneck Evidence: [BOTTLENECK_EVIDENCE]
- Constraints: [CONSTRAINTS]
- Team Operational Maturity: [TEAM_MATURITY]

## Output Schema
Return a JSON object with the following structure:
{
  "executive_summary": "A 2-3 sentence recommendation with primary rationale.",
  "dimension_analysis": [
    {
      "dimension": "Cost Efficiency",
      "horizontal_scaling_assessment": "...",
      "vertical_scaling_assessment": "...",
      "winner": "horizontal" | "vertical" | "context_dependent"
    },
    {
      "dimension": "Operational Simplicity",
      "horizontal_scaling_assessment": "...",
      "vertical_scaling_assessment": "...",
      "winner": "horizontal" | "vertical" | "context_dependent"
    },
    {
      "dimension": "Availability Impact",
      "horizontal_scaling_assessment": "...",
      "vertical_scaling_assessment": "...",
      "winner": "horizontal" | "vertical" | "context_dependent"
    },
    {
      "dimension": "Workload Suitability",
      "horizontal_scaling_assessment": "...",
      "vertical_scaling_assessment": "...",
      "winner": "horizontal" | "vertical" | "context_dependent"
    }
  ],
  "single_point_of_failure_analysis": "Identify any single points of failure introduced or left unresolved by each strategy.",
  "recommended_strategy": "horizontal" | "vertical" | "hybrid",
  "implementation_risks": ["Risk 1", "Risk 2"],
  "decision_triggers": "Describe conditions that would flip the recommendation (e.g., if traffic doubles, if budget is cut by 30%)."
}

## Constraints
- Do not assume a cloud provider unless specified in the input context.
- If the workload is stateful, explicitly address how state management affects the scaling choice.
- Flag any assumption you are making that is not supported by the provided context.
- If the input context is insufficient to make a recommendation, state what additional data is required.

To adapt this prompt, replace the placeholders with real data. For [SYSTEM_DESCRIPTION], include the service's architecture, current instance size, and traffic patterns. For [WORKLOAD_CHARACTERISTICS], specify whether the workload is CPU-bound, memory-bound, I/O-bound, stateful, or stateless. The [BOTTLENECK_EVIDENCE] placeholder should contain monitoring data, such as CPU saturation, memory pressure, or connection limits. If you are using this in a high-stakes production environment, add a [RISK_LEVEL] placeholder and a final instruction to route the output to a human for approval before any infrastructure changes are executed.

This prompt is designed to be embedded in a capacity planning review workflow, not a real-time chat interface. The primary integration point is a structured form or API that collects the required inputs—[WORKLOAD_PROFILE], [CURRENT_ARCHITECTURE], [SCALING_REQUIREMENTS], [CONSTRAINTS], and [TEAM_CAPABILITY]—and submits them to the model. Because the output is a decision memo that influences infrastructure spend and availability, the implementation must treat this as a high-stakes, asynchronous job with mandatory validation and human approval before any downstream automation consumes the recommendation.

Validation and retry logic is critical. The model's output must conform to the [OUTPUT_SCHEMA], which includes a structured trade-off matrix and a ranked recommendation. Implement a post-generation validator that checks for: (1) valid JSON structure, (2) presence of all required dimensions (cost efficiency, operational simplicity, availability impact, workload suitability), (3) a non-empty single_points_of_failure array, and (4) a confidence_score between 0 and 1. If validation fails, retry up to two times with a repair prompt that includes the specific validation error and the original context. After two failed retries, escalate to a human reviewer queue with the raw output and error log. For model choice, use a model with strong reasoning capabilities (e.g., GPT-4o, Claude 3.5 Sonnet) and set temperature=0.2 to balance structured analysis with some exploration of edge cases. Do not use a small or fast model for this task; the cost of a bad scaling decision far outweighs token savings.

Human-in-the-loop integration is mandatory. After successful validation, route the output to a review dashboard that displays the trade-off matrix, the top recommendation, and the identified single points of failure. The reviewer must explicitly approve, reject with notes, or request a re-run with modified constraints. Log every decision, the reviewer's identity, and the timestamp for audit trails. Never automatically apply the recommended scaling strategy to infrastructure-as-code pipelines or auto-scaling groups without this approval step. The prompt's single_points_of_failure field is your primary safety net—if the model identifies a critical SPOF that the team hasn't mitigated, the review should block until a mitigation plan is documented.