API performance audit: find the work behind the latency

Audit API latency with percentile distributions, traces, database evidence, queue timing and bounded load experiments tied to business journeys.

An API performance audit should explain where time is spent and how the system behaves as demand changes. An average response time hides slow requests, while a single load-test number says little about correctness. Start with critical operations, representative payloads and a clear service objective. Record the environment and protect shared systems with an agreed load boundary and stop conditions.

Build a trustworthy baseline

Measure request rates, latency distributions, errors and resource saturation over a meaningful period. Separate successful and failed responses, because fast failures can make aggregate latency look better. Group by route and relevant workload characteristics rather than combining a lightweight lookup with a large export. Confirm the timing boundary: client-observed duration includes different work from server handler time. Correlate requests with traces using identifiers that do not expose sensitive payloads.

Follow one slow request

Inspect database queries, external calls, lock waits, connection pools, serial work and response size. Look for repeated queries driven by the number of returned records. Check query plans with representative data and indexes, not an empty development database. For asynchronous work, distinguish time waiting in a queue from time executing a job. A quick accepted response does not prove that the underlying business operation finishes promptly.

Test one hypothesis at a time

• Reproduce the slow operation with realistic data shape and a controlled request rate.
• Change a specific cause, such as a missing index, unnecessary serial call or oversized response.
• Verify correctness, authorisation and ordering before comparing the performance result.
• Increase demand gradually within the agreed boundary and observe errors, queue growth and recovery.

Report capacity as a conditional result

State the environment, workload, data set and limits of the measurement. Avoid presenting a development benchmark as a production guarantee. Assign actions to the dominant bottlenecks and record trade-offs: a cache may reduce latency while requiring invalidation, and a background job may improve response time while increasing completion delay. The audit should leave the team with a reproducible baseline, prioritised repairs and monitoring that can detect recurrence. It should also identify which capacity questions remain untested and what evidence would resolve them. Record the exact software revision used for comparison.

• Performance and modernization →
• API Integration Checklist: Questions Before Development Starts →
• Next.js Performance: Diagnosing Slow Pages and Large Bundles →