Each test is 5 questions with varying difficulty.
AI Prep covers AI Agents, Generative AI, ML Fundamentals, NLP & LLMs and a lot more, with adaptive tests and daily challenges. Fully offline on Android. Free to try, one-time unlock for lifetime access.
API pagination strategies are fundamental to building scalable, performant, and reliable web services in 2026. As datasets grow into the millions of records, returning full collections becomes impossible due to memory, latency, and bandwidth constraints. Pagination allows clients to request data in manageable chunks, ensuring consistent response times regardless of total dataset size. For software engineers, AI engineers, and backend developers, understanding these strategies is critical for designing robust interfaces. Interviewers prioritize this topic because it tests a candidate's ability to balance performance, user experience, and data consistency in distributed environments. Junior candidates are expected to understand the basic trade-offs between offset and cursor-based approaches, while senior candidates must demonstrate mastery over complex scenarios, such as maintaining consistency during concurrent writes, handling large-scale database sharding, and optimizing for high-throughput streaming APIs.
In modern production systems, inefficient pagination is a primary driver of database performance degradation. A common anti-pattern is the use of 'OFFSET' in SQL queries on large tables; as the offset value increases, the database must scan and discard thousands of rows, leading to linear latency growth (O(N)). In 2026, with the rise of real-time data streaming and AI-driven data retrieval, APIs must handle high-frequency requests without locking up underlying storage engines. Companies like Stripe or Shopify rely on cursor-based pagination to ensure that clients can traverse massive datasets without missing records or seeing duplicates, even when new items are inserted during the traversal. This topic is a high-signal interview area: a weak candidate will suggest 'OFFSET/LIMIT' without considering the performance hit, while a strong candidate will discuss the implications of index usage, the necessity of stable sort keys, and how to maintain state across distributed nodes. Mastering this topic signals that a candidate understands the intersection of network protocols, database internals, and client-side consumption patterns.
The pagination execution model relies on the interaction between the API Gateway, the Application Server, and the Database Index. When a request arrives, the server parses the pagination parameters (limit/cursor), constructs a query that utilizes a specific index, and executes it against the database. The result set is then serialized, and a 'next' cursor is generated based on the last record's values.
[Client Request]
↓
[API Gateway (Validation)]
↓
[Application Server (Cursor Logic)]
↓
[Query Planner (Index Selection)]
↓
[Database (B-Tree Index Scan)]
↓
[Result Set (Data Extraction)]
↓
[Cursor Encoder (Base64)]
↓
[Client Response (Data + Next Cursor)]Standardizes pagination using 'edges', 'nodes', and a 'pageInfo' object containing the cursor.
Trade-offs: Increases payload size but provides a predictable, client-friendly interface.
Uses tuple comparison (e.g., WHERE (a, b) > (val_a, val_b)) to leverage composite indexes.
Trade-offs: Requires specific composite indexes; less flexible than simple ordering.
Encodes the cursor state as a base64 string to prevent clients from guessing internal IDs.
Trade-offs: Prevents client-side cursor manipulation but requires decoding on the server.
| Reliability | Use deterministic sort keys to ensure that pagination remains stable even when records are added or deleted during the traversal process. |
| Scalability | Horizontal scaling is achieved by ensuring queries are index-backed, preventing heavy load on the primary database instance. |
| Performance | Target O(log N) query complexity by leveraging composite indexes; avoid full table scans at all costs. |
| Cost | Minimize database CPU and I/O usage by reducing the amount of data scanned per request, directly lowering infrastructure costs. |
| Security | Always use opaque cursors to prevent information leakage about the database schema or internal record counts. |
| Monitoring | Track 'query_latency' and 'index_hit_ratio' specifically for paginated endpoints to identify bottlenecks. |
Offset pagination uses a fixed number of rows to skip (e.g., OFFSET 100), which is slow on large datasets because the database must scan and discard the skipped rows. Cursor-based pagination uses a pointer (cursor) to the last retrieved record, allowing the database to jump directly to the next set of results using an index, making it significantly more performant and stable.
It suffers from O(N) performance degradation. As the offset increases, the database must perform more work to reach the desired page, leading to increased latency and CPU usage. Additionally, if new items are inserted into the dataset while a user is paginating, offset pagination can cause records to be skipped or duplicated across pages.
To ensure consistency, you must use a deterministic sort order. Always include a unique column (like a primary key or a timestamp with a UUID) in your ORDER BY clause. This ensures that the cursor points to a specific, immutable position in the dataset, preventing duplicates or missing records during concurrent writes.
Yes. Opaque cursors (usually base64-encoded strings) decouple the API contract from the database schema. They prevent clients from guessing internal IDs, protect against information leakage, and allow you to change the underlying database implementation without breaking the API for existing clients.
Technically yes, but it will be inefficient. Keyset pagination relies on the database's ability to perform a range scan using the sort keys. Without a composite index covering the sort columns, the database may fall back to a full table scan, negating the performance benefits of the keyset approach.
In a sharded database, pagination becomes complex because data is distributed across multiple nodes. You need a sharding-aware cursor that includes the shard key, or you must aggregate results from all shards, which can be slow. Designing cursors that incorporate shard information is key to maintaining performance in distributed systems.
GraphQL often uses the 'Relay Connection' specification, which standardizes cursor-based pagination with a specific structure (edges, nodes, pageInfo). REST APIs are more flexible but often lack this standardization. Both can implement the same underlying cursor-based logic, but GraphQL provides a more formal contract for the client to follow.
It occurs when an API fetches a page of records (1 query) and then performs an additional query for each record to fetch related data (N queries). In pagination, this can be devastating to performance. Use techniques like eager loading or batching to fetch related data in a single query alongside the paginated results.
Without limits, a malicious or poorly written client could request a page size of 1,000,000 records, leading to memory exhaustion on your application server and database timeouts. Enforcing a maximum page size is a critical layer of defense for API availability and resource management.
Streaming data is often better handled with WebSockets or Server-Sent Events (SSE) rather than traditional pagination. However, if you must paginate, use a cursor based on a high-resolution timestamp or sequence number to ensure you capture the stream state accurately without missing events.
AI Prep covers AI Agents, Generative AI, ML Fundamentals, NLP & LLMs and a lot more, with adaptive tests and daily challenges. Fully offline on Android. Free to try, one-time unlock for lifetime access.