Keyset pagination helps load data faster by using a fixed point to continue fetching results instead of counting all items each time.
Keyset pagination for performance in Rest API
Start learning this pattern below
Jump into concepts and practice - no test required
GET /items?limit=10&after_id=123
limit sets how many items to fetch per page.
after_id tells the server to return items with IDs greater than this value.
GET /products?limit=20&after_id=50
GET /messages?limit=15&after_id=200
GET /posts?limit=10This simple REST API returns items in pages using keyset pagination. It uses the 'after_id' query to fetch items with IDs greater than the given value. If no 'after_id' is given, it returns the first page.
from flask import Flask, request, jsonify app = Flask(__name__) # Sample data: list of items with id and name items = [{'id': i, 'name': f'Item {i}'} for i in range(1, 101)] @app.route('/items') def get_items(): limit = int(request.args.get('limit', 10)) after_id = request.args.get('after_id') if after_id is not None: after_id = int(after_id) filtered = [item for item in items if item['id'] > after_id] else: filtered = items result = filtered[:limit] return jsonify(result) if __name__ == '__main__': app.run(debug=True)
Keyset pagination is faster than offset pagination because it avoids counting or skipping rows.
Use a unique and indexed column (like an ID) for the cursor to keep results consistent.
Remember to handle the case when there are no more items to fetch.
Keyset pagination uses a fixed point (cursor) to fetch the next page of results efficiently.
It is great for large datasets and real-time feeds where counting all items is slow.
Use query parameters like limit and after_id to control pagination.
Practice
keyset pagination over traditional offset-based pagination in REST APIs?Solution
Step 1: Understand offset-based pagination issues
Offset pagination uses a page number and offset, which becomes slow on large datasets because the database must skip many rows.Step 2: Recognize keyset pagination benefits
Keyset pagination uses a fixed key (like an ID) to fetch the next set of rows, avoiding the costly skip operation and improving performance.Final Answer:
It improves performance by avoiding slow offset queries on large datasets. -> Option CQuick Check:
Keyset pagination = better performance [OK]
- Thinking keyset allows random page jumps
- Assuming keyset caches all data
- Believing keyset changes sort order automatically
users ordered by id?Solution
Step 1: Identify keyset pagination syntax
Keyset pagination uses a WHERE clause with a key (like id > last_seen_id) and a LIMIT to fetch the next page.Step 2: Analyze each option
SELECT * FROM users WHERE id > 20 ORDER BY id LIMIT 10; usesWHERE id > 20withORDER BY id LIMIT 10, which matches keyset pagination logic.Final Answer:
SELECT * FROM users WHERE id > 20 ORDER BY id LIMIT 10; -> Option BQuick Check:
Keyset uses WHERE key > last_key [OK]
- Using OFFSET instead of WHERE for pagination
- Using equality (=) instead of greater than (>)
- Not ordering results by the key column
GET /items?last_id=50&limit=5
And the database table
items with IDs: [45, 47, 50, 52, 55, 60, 65], what will be the IDs returned by this request?Solution
Step 1: Understand keyset pagination with last_id=50
The API returns items with IDs greater than 50, limited to 5 results.Step 2: Select IDs greater than 50 from the list
IDs greater than 50 are [52, 55, 60, 65]. There are only 4 such items, so all are returned.Final Answer:
[52, 55, 60, 65] -> Option AQuick Check:
IDs > 50 limited to 5 = [52, 55, 60, 65] [OK]
- Including items with ID equal to last_id
- Using offset instead of key comparison
- Assuming IDs are continuous numbers
SELECT * FROM orders WHERE order_date > '2024-01-01' ORDER BY order_date LIMIT 10;
But it returns duplicate rows when new orders are added. What is the likely cause?
Solution
Step 1: Identify ordering column uniqueness
Ordering byorder_datealone can cause duplicates if multiple rows share the same date.Step 2: Understand keyset pagination requirements
Keyset pagination requires ordering by a unique column or combination to avoid duplicates and missing rows.Final Answer:
Ordering by a non-unique column causing duplicates -> Option AQuick Check:
Order by unique key to avoid duplicates [OK]
- Thinking OFFSET fixes duplicates
- Using >= instead of > causes duplicates
- Assuming LIMIT controls duplicates
price ascending, then by id ascending to break ties.Which SQL WHERE clause correctly fetches the next page after last product with
price=100 and id=50?Solution
Step 1: Understand multi-column keyset pagination
When ordering by multiple columns, the WHERE clause must handle the first column and then the second to break ties.Step 2: Analyze the correct condition
The correct condition isprice > 100 OR (price = 100 AND id > 50)to get all rows with higher price or same price but higher id.Final Answer:
WHERE price > 100 OR (price = 100 AND id > 50) -> Option DQuick Check:
Multi-column keyset uses OR + AND for tie-break [OK]
- Using AND instead of OR for first column
- Ignoring tie-break column in WHERE clause
- Using >= instead of > causing duplicates
