API performance

Overview

API performance is about latency (how long one request takes, especially at P95 and P99) and throughput (how many requests per second the system sustains). Most slow APIs are slow for a few recurring reasons: too many database queries, missing indexes, large payloads, sequential calls to other services, and no caching.

The process is always measure first: trace a slow request, find where time is spent, then fix the biggest contributor. Typical fixes are caching, batching, parallelizing independent calls, pagination, compression, connection pooling, and moving slow work to background jobs.

When to use it

• Endpoints miss latency targets (SLOs).
• Traffic growth is increasing costs or errors.
• Mobile clients suffer from payload size or round trips.
• Interview deep dives: 'this endpoint is slow, what do you do?'.

Where it shows up in interviews

Where it is used in real software

Key terms

P50 / P95 / P99

Latency percentiles; tail latency affects many users on pages with many calls.

N+1 queries

One query per item in a list instead of a single batched query.

Fan-out

One request calls several services; latency is set by the slowest.

Payload size

Bytes transferred; affects network time, especially on mobile.

A method for fixing a slow endpoint

1. 1
   Measure

   Collect P50/P95/P99 and trace slow requests end to end.

2. 2
   Find the dominant cost

   Database, downstream calls, serialization, or network transfer.

3. 3
   Fix data access

   Add indexes, remove N+1 queries, select only needed columns.

4. 4
   Cache and batch

   Cache hot reads, batch lookups, and parallelize independent calls.

5. 5
   Shrink responses

   Paginate, trim fields, compress.

6. 6
   Move work off the request path

   Send emails, generate reports, and update analytics asynchronously.

Optimizing a product page API

Initial P95 = 1,200 ms

Each change targeted the largest remaining cost. Guessing (for example, upgrading servers first) would have cost money without fixing the queries.

Implementation

1// Before: sequential calls, latency = sum of all three2async function productPageSlow(id: string) {3  const product = await catalog.get(id);4  const price = await pricing.get(id);5  const stock = await inventory.get(id);6  return { product, price, stock };7}8 9// After: cache + parallel independent calls with a timeout budget10async function productPage(id: string) {11  const cached = await redis.get(`product:${id}`);12  const product = cached ? JSON.parse(cached) : await catalog.get(id);13  if (!cached) await redis.set(`product:${id}`, JSON.stringify(product), { EX: 60 });14 15  const [price, stock] = await Promise.all([16    withTimeout(pricing.get(id), 150),17    withTimeout(inventory.get(id), 150).catch(() => ({ status: "unknown" })), // degrade gracefully18  ]);19  return { product, price, stock };20}21 22function withTimeout<T>(promise: Promise<T>, ms: number): Promise<T> {23  return Promise.race([24    promise,25    new Promise<T>((_, reject) => setTimeout(() => reject(new Error("timeout")), ms)),26  ]);27}

Complexity and performance

Trade-offs

Variants and related techniques

Common mistakes

• Optimizing without measuring.

  Fix: Profile and trace first; fix the largest contributor.

• Looking only at averages.

  Fix: Track P95/P99; tail latency is what users notice.

• Unbounded list endpoints.

  Fix: Always paginate and cap limits.

Interview questions

Practice problems