How do you optimize API response times?

expert

Re-explain

Measure first, then fix the slowest part of the request path. Track latency percentiles such as the 99th alongside error rates, because an average hides the slow tail users notice. Distributed tracing and APM tools show where each slow request spends its time.

The database is the usual bottleneck. Index the columns your queries filter and join on, and check slow queries with EXPLAIN. Fix N+1 queries, where a loop runs one query per item, with a join or one batched query. Connection pooling avoids a new connection per request. Read replicas spread read load, but they can lag, so reads that must see a fresh write go to the primary.

Caching skips the work. Keep hot data in Redis with a TTL, and clear it when the data changes. Send Cache-Control and ETag headers, so clients, CDNs and an API gateway can reuse responses. An unchanged resource then comes back as a bodiless 304 Not Modified.

Then shrink the response. Field selection lets a client ask only for what it needs, as in GET /users?fields=id,name,email. Compress responses with gzip, paginate long lists, and leave related resources out until the client asks for them.

Move heavy work off the request path. Async processing and background job queues let the API answer at once with 202 Accepted. Splitting into microservices helps scaling, not latency, because every remote call adds a network hop.

Rewriting in plainer words…

This answer doesn't lend itself to a diagram - it reads best . No credits were charged.

Why there's no diagram: “”

The interactive diagram is below the answer - jump to diagram ↓ · Below it, the related concept . Jump to it ↓

The diagram below the answer is the concept . Jump to it ↓

Tailored explanation · switch back to · ·

What should the new diagram focus on?

Guided practice for API Design One question at a time. Answer out loud, get graded, see what you missed.

Related concept

Scale and availability: what statelessness makes possible, and what still fails

Holding no session is what lets the servers scale out. For availability, the other half, assume parts fail and stop one failure from spreading.

For this question · chapter 2 of 3This answer says to measure first, then fix the slowest part. Watch 950 ms of waiting split into its parts. Then watch caching remove 560 ms and sharding remove only 25 ms, so caching comes first and sharding comes last.

2/3 Use these in order

Use these in order

The servers are now replaceable, so you could add one, but try these options first. Their order matters more than the list itself. At three thousand requests a second, checkout answers in 950 ms at the 95th percentile. Each row names one real part of that wait, and the rows add up to 950 ms. A bigger server is already used up, because doubling the machine is a real first move that stops at one machine.
Caching the hot reads comes first, because an afternoon of work removes 560 ms, more than half the wait. The same product page is requested 82 times a second, and a cache answers that page once instead of 82 times. The cost is stale data: a read can return a page up to a minute old. You also have to handle invalidation now, which means removing a cached page when the product data changes.
The primary database is answering reads that it never had to answer. Reads outnumber writes about ten to one here, so sending the reads to replicas (copies of the database) saves 80 ms. The cost has a name that interviewers listen for: replication lag, the delay before a write reaches the replicas. A read straight after a write can miss that write, so any path that must see its own write stays on the primary.
Connection pooling needs no new machines and no new service, only one setting. Opening a new database connection for every request costs more than most of the queries run on that connection. Reusing open connections from a pool takes 27 ms off the wait. But pool size becomes a limit you have to tune, and one slow query now holds a connection that another request wanted.
Moving work off the request saves time by changing the contract with the client. The confirmation email goes out inside the request, so the request waits for the email. Put the email on a queue instead, and the request stops waiting, which cuts 60 ms from the response time. An asynchronous API is this trade: the client gets a 202 now and finds out the result later.
Sharding (splitting the data across databases) comes last, and the numbers show why. Sharding cuts 25 ms from this p95 latency, the smallest saving of any option here. And sharding adds costs: every query now needs a shard key, you give up cross-shard joins, and you need a plan to rebalance the data. So shard when one database runs out of capacity, not to make a request faster.
Most of performance work is knowing which part of the wait nothing can remove. Field selection and gzip shrink the JSON from 180 kB to 24 kB, so the wait drops by 90 ms here. Sending less saves more over mobile, because bandwidth and battery both cost the user something there. The 108 ms left after this last optimization is the endpoint doing its work, and no optimization removes that time.

Chapter 2 · step 1 of 7

The servers are now replaceable, so you could add one, but try these options first. Their order matters more than the list itself. At three thousand requests a second, checkout answers in 950 ms at the 95th percentile. Each row names one real part of that wait, and the rows add up to 950 ms. A bigger server is already used up, because doubling the machine is a real first move that stops at one machine.

1 of 7 Use ← → or swipe See the concept: all 3 chapters in it

How well did you know this?

AI:

Saved in this browser - sign in to keep your review list.

How should your speech become text?

Listening… your words appear above as you speak - tap Stop when you're done.

Recording · cr - tap Stop & transcribe when you're done.

Transcribing with AI…

Voice:

Keep going - a few more words and AI can grade it.

Interview lens How interviewers actually use this question

Likely follow-ups

Your average latency looks fine but p99 is slow. How do you find where the time goes? Trace the slow requests themselves and find the span that grows. Look for a slow query on large accounts, lock waits or a slow downstream call.
After a write, how do you stop the Redis cache from serving the old value? Delete or update the key on write and keep the TTL as a backstop. Name the race where a concurrent read puts the old value back in the cache.
A hot cache key expires and hundreds of requests hit the database at once. What do you do? Call it a cache stampede. Let one request rebuild the value while others wait or get stale data, and add jitter to TTLs so keys don't expire together.
You add read replicas. How do you handle a user who writes and then reads their own data? Replicas lag, so send that user's reads to the primary, for example for a short window after their write.
Deep pages of a list endpoint get slow with offset pagination. What would you change? Offset makes the database scan and skip every earlier row. Use cursor or keyset pagination on an indexed, unique sort key.

What you can say

I measure first, then fix the slowest part of the request path.
I watch p99 latency next to error rates, because an average hides the slow tail, and I use tracing to see where a slow request spends its time.
The database is usually the culprit, so I check slow queries with EXPLAIN, index the columns I filter and join on, replace N+1 loops with a join or a batch, and pool connections.
Next I cache. Hot data goes in Redis with a TTL and gets cleared on writes, and Cache-Control and ETag headers let clients and CDNs reuse responses or get a 304.
Then I shrink the payload with field selection, gzip and pagination, and I move heavy work to a background queue so the API can answer right away with 202 Accepted.
I wouldn't split into microservices for speed. That helps scaling, but every remote call adds a network hop, so a single request doesn't get faster.

Weak answers to avoid

Jumps straight to caching Caching before measuring can hide a missing index or an N+1 query and adds stale-data bugs. Say how you find the slow part first, then fix it.
Quotes average response time An average hides the slow tail users actually feel. Talk about p99 next to error rates, and tracing to see where slow requests spend their time.
Says microservices will make it faster Splitting services helps scaling, not latency. Every remote call adds a network hop, so a request that crosses services gets slower.
Lists techniques with no trade-offs A cache can serve stale data and has to be invalidated, and read replicas can lag. Name the cost of each fix, such as sending reads that must see a fresh write to the primary.

Interview lens

Likely follow-ups, what you can say, and the weak answers to avoid.

Want a quick review of the fundamentals? See the API Design cheatsheet.

← Back to all API Design questions

Pro · $10/mo

74 of 92 API Design answers are in Pro.

Full answers, code samples, and AI explanations that go simpler or deeper. Cancel anytime.

Full answers + code
AI explanations, simpler or deeper
1,000 AI credits / month
Cancel anytime

Get Pro → See plans & pricing →