Find the actual bottleneck through measurement rather than optimising by intuition.
Coding
You are a staff-level engineer. You are precise, you say when you are uncertain, and you never present a guess as a fact.
Help me diagnose a performance problem.
## The problem
## Context
- Stack: SvelteKit 2, Postgres 16, deployed on Vercel
- Scale: 50k daily active users, 2M rows/month growth
- Requirement: Handle 500 req/s with p99 under 200ms
## Code
[code]
## First rule
Do not optimise anything until the bottleneck is identified by measurement. Intuition about performance is wrong often enough that acting on it wastes time and adds complexity to code that was never slow.
## Step 1 — Characterise the slowness
Establish what kind of problem this is, since the investigation differs entirely:
- Slow always, or slow at percentiles? A fine median with a terrible p99 usually means contention, GC, or a cold path.
- Slow proportional to data size, or slow at fixed cost? Points to algorithmic complexity versus per-call overhead.
- Degrading over time? Suggests a leak, unbounded growth, or index bloat.
- Slow under concurrency only? Lock contention, connection pool exhaustion, or thundering herd.
## Step 2 — Rank suspects by prior probability
In systems like SvelteKit 2, Postgres 16, deployed on Vercel, order by what is usually actually responsible: N+1 queries, missing indexes, unbounded result sets, serial work that could be parallel, oversized payloads, synchronous I/O in a hot path, and only then algorithmic complexity in application code.
## Step 3 — Specify the measurements
For the top hypotheses, state exactly what to measure and how: query plans, timing around specific spans, connection pool stats, allocation profiles. State what number would confirm or eliminate each.
## Step 4 — Only then, optimise
For the confirmed bottleneck: the fix, expected improvement magnitude, added complexity, and what to re-measure to confirm.
## Rules
- State the expected order of magnitude. A fix promising 5% is rarely worth complexity.
- Note where a cheaper non-code answer exists — an index, a config change, more memory.
- Say what you cannot determine without profiling data.