Does my app need load balancing?

Paste this into the agent that already has your project open — Claude Code, Cursor, Codex, Copilot, Cline, Windsurf, Aider, whichever you use. Let it read the repository before it answers.

You are acting as a pragmatic infrastructure reviewer for this project. I am the builder. I
am not an infrastructure engineer, so explain everything in plain English and define any term
the first time you use it.

Answer one question: does this application need load balancing, and if so, when and how?

Work in the five steps below, in order. Do not skip a step. Do not start writing code.

=== STEP 1 · INSPECT WHAT ACTUALLY EXISTS ===
Read the repository before you say anything. Report what you FOUND, with file paths, and mark
anything you could not determine as UNKNOWN rather than guessing:
- Language, framework and runtime, with versions.
- How the app is served: one long-running process, several processes, serverless functions,
  containers, a static site with an API behind it, something else.
- Where it is hosted or deployed to, if the repo says. Look at deployment config, Dockerfiles,
  CI workflows, platform config files, infrastructure-as-code, and any README or docs.
- Every datastore, cache, queue and third-party service it depends on.
- Anything that holds state in the memory of a single process: in-memory sessions, in-memory
  caches, rate-limit counters, uploaded files written to local disk, websocket or SSE
  connections, background timers, cron loops, in-process job queues, singletons.
- Any startup work that is slow or that assumes it runs exactly once.
List the UNKNOWNs explicitly. They matter more than the things you found.

=== STEP 2 · TRACE THE TRAFFIC ENTRY POINT AND THE SINGLE POINTS OF FAILURE ===
- Draw the request path as a numbered list, from the user's browser or app to the response:
  what receives the request FIRST, and what each hop hands it to.
- Name every point where all traffic funnels through exactly one thing: one process, one
  container, one function concurrency limit, one database, one disk, one third-party account.
- For each one, say what the user experiences when it saturates: slower pages, timeouts,
  dropped connections, failed writes, lost uploads, wrong data.
- Say which single point of failure would bite FIRST. Usually it is not the web server.

=== STEP 3 · ESTIMATE THE LOAD HONESTLY ===
Do NOT invent traffic numbers. Instead:
- Search the repo for real evidence: analytics config, logging, existing metrics dashboards,
  rate limits already set, plan tiers in config, load tests, prior incident notes.
- If there is no evidence, say so, then ASK ME these questions and wait for my answers before
  continuing: How many people use it today, at peak? What is the biggest plausible spike in
  the next three months, and what would cause it? Are requests short (a page load) or long
  (a file upload, an AI call, a report)? Is downtime embarrassing, expensive, or dangerous?
- Then classify the workload as one of:
  (a) SIMPLE LAUNCH — low, bursty, human-paced traffic; requests finish in well under a
      second; an outage is embarrassing but survivable.
  (b) SUSTAINED OR LONG-RUNNING — steady concurrency, or individual requests that hold a
      process for seconds or minutes (AI generation, uploads, exports, streaming, websockets).
  (c) HIGH-TRAFFIC OR CRITICAL — real concurrency at peak, or money/safety on the line.
- Show the arithmetic behind the classification: concurrent requests ≈ requests per second ×
  average seconds per request. State every assumption as an assumption.

=== STEP 4 · GIVE ME A RECOMMENDATION, INCLUDING "NOT YET" ===
State one clear recommendation and defend it. These are all valid answers:
- "No load balancer yet." Say this if it is true. If the platform already spreads traffic for
  me, or the real bottleneck is the database, or the traffic does not justify the operational
  cost, say that plainly and tell me what to do INSTEAD and what signal should change my mind.
- "Not a load balancer, fix X first." Say this if a cheaper change (an index, caching, a CDN,
  moving one slow job off the request path) buys more than another server would.
- "Yes, and here is the phased path."
Then give me PHASED OPTIONS, cheapest first. For each phase: what it is in one sentence, what
it costs in money AND in ongoing operational work, what it protects against, what it does NOT
protect against, and the specific signal that means it is time to move to the next phase.
Be explicit that adding servers behind a balancer does nothing if the bottleneck is a shared
database, and say whether that is my situation.

=== STEP 5 · EXPLAIN THE RECOMMENDED IMPLEMENTATION IN PLAIN ENGLISH ===
Write it as a plan I could hand to someone else. No code yet. Cover every one of these, and
for each one say whether it applies to MY app and why:
- Health checks: what the balancer asks each server to decide it is alive, what that endpoint
  must check, and why a check that always returns OK is worse than none.
- Sticky sessions and in-memory state: what breaks the moment a user's second request lands on
  a different server, and how to fix it properly (move session and cache state to a shared
  store) rather than pinning users to one server.
- Websockets and long-lived connections: whether my app has any, and what they need.
- File uploads and anything written to local disk: why per-server disks stop working behind a
  balancer, and where those files should go instead.
- Background jobs, cron and scheduled work: what happens when the same job runs on every
  server at once, and how to make it run exactly once.
- The database: connection limits and pooling as server count grows, read/write split,
  whether the database becomes the new single point of failure, and how I would know.
- Caching and CDN: what should never reach my servers at all.
- Rate limiting and abuse: why a per-process counter stops working across several servers.
- Observability: the specific things I must be able to see BEFORE this matters — request rate,
  latency percentiles, error rate, saturation per server — and what to alert on.
- Graceful shutdown and deploys: how a server leaves the pool without dropping live requests.
- Testing and rollback: how to verify the change under realistic concurrency, what "it worked"
  looks like in numbers, and the exact steps to undo it.

=== HARD RULES ===
- Do NOT deploy, provision, scale, migrate, change any hosting or infrastructure setting, run
  any destructive command, or modify production. Not now, not as a "quick check".
- Do NOT edit application code in this pass. This pass produces a written answer only.
- If you want to change anything at all, describe the change and STOP for my approval.
- Never fabricate traffic numbers, costs, benchmarks, or platform behaviour. If you are not
  sure what my hosting platform does by default, say "I need to check" and tell me exactly
  what to look up.
- Distinguish clearly between what you READ in my repo, what you INFERRED, and what you are
  ASSUMING.
- If the honest answer is "this is fine as it is", say that, and be specific about what would
  have to change for it to stop being fine.

=== OUTPUT FORMAT ===
1. Verdict in one sentence.
2. What I found (with file paths) and what is UNKNOWN.
3. The request path, and the first thing that breaks.
4. Load estimate, with assumptions labelled.
5. Phased options with costs and tradeoffs.
6. The recommended plan in plain English, covering the checklist above.
7. What to do this week, and what to leave alone.