Api Design medium
Your API lists 10 million orders. A client paginates with offset=5,000,000&limit=20. The database query is extremely slow. Why, and what's the fix?
- A Offset pagination requires the database to scan and discard millions of rows, leading to high CPU/IO. Use cursor-based pagination (keyset) to seek directly to a unique identifier.
- B The primary database instance is overloaded by the query complexity. Scale out by adding read replicas to handle the high volume of parallel offset-based scan operations.
- C The application layer is performing an O(N) filter operation on the full dataset before returning the page. Move the offset logic into a stored procedure for localized execution.
- D The database lacks a Bloom Filter on the primary key, causing every offset request to trigger a full table scan. Enable probabilistic indexing to quickly skip to the 5 millionth row.
Answer: A. Offset pagination requires the database to scan and discard millions of rows, leading to high CPU/IO. Use cursor-based pagination (keyset) to seek directly to a unique identifier.
Offset-based pagination (`OFFSET N`) scales linearly (O(N)) because the database must scan and discard N rows to find the start of the results. This becomes prohibitively slow for large offsets (e.g., 5 million). **Cursor-based pagination** (or keyset pagination) solves this by using a unique index (like `ID`) to seek directly to the last seen record (`WHERE id > last_seen_id`), making the query efficient (O(Limit)) regardless of how deep into the dataset you are.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- You're designing a REST API for a blog. Which endpoint best represents 'get all comments for post 123'?
- A client wants to update only the 'status' field of an order, leaving other fields unchanged. Which HTTP method is most appropriate?
- A client calls POST /users with valid data, and the user is created. What status code should the server return?
- A client retries a failed 'POST /payments' request due to network timeout. The server receives the request twice. Without idempotency handling, what can happen?
- An API returns 10,000 products. Returning all in one response is impractical. Which pagination approach is simple and stateless?
- Your API serves both mobile apps and third-party integrations. Which authentication method is most appropriate?