Pagination Types
Offset-Based Pagination
GET /products?page=2&limit=20
Response:
{
"data": [...],
"pagination": {
"page": 2,
"limit": 20,
"total": 150,
"totalPages": 8
}
}
SQL: SELECT * FROM products LIMIT 20 OFFSET 20;
Pros: Simple, supports "jump to page"
Cons: Inconsistent with concurrent inserts/deletes
Cursor-Based Pagination
GET /products?limit=20&cursor=eyJpZCI6MTIzfQ==
Response:
{
"data": [...],
"pagination": {
"nextCursor": "eyJpZCI6MTQzfQ==",
"hasMore": true
}
}
SQL: SELECT * FROM products WHERE id > 123 LIMIT 20;
Pros: Consistent, performant on large datasets
Cons: Can't jump to specific page
Keyset (Seek) Pagination
GET /products?sort=created_at,id&after=2025-01-15T10:00:00Z&limit=20
Comparison
| Type | Jump to Page | Consistent | Performance | Complexity |
|---|---|---|---|---|
| Offset | Yes | No | Degrades at offset | Low |
| Cursor | No | Yes | Constant | Medium |
| Keyset | No | Yes | Constant | High |
Pagination Best Practices
Types
- Offset: Simple, but slow for large offsets
- Cursor: Consistent, better performance
- Keyset: Composite key ordering
Response Format
{
"data": [...],
"pagination": {
"page": 1,
"pageSize": 20,
"total": 100,
"hasMore": true
}
}
Best Practices
- Default page size: 20-50
- Maximum page size: 100
- Use cursor for large datasets
Key Points
- Understanding Pagination is essential for production systems
- Always consider scalability and maintainability
- Test thoroughly before deploying to production
- Monitor performance and set up alerting
Common Patterns
- Validation: Always validate input at the boundary
- Error Handling: Use structured error responses
- Logging: Log key events for debugging
- Testing: Unit, integration, and load tests
- Documentation: Keep docs updated with code changes
Practice Problems
Design and implement a solution for Pagination in a backend system. Consider scalability, error handling, and production readiness.
Solution
// Pagination implementation
// Key aspects: validation, error handling, logging, testing
public class Pagination {
// Production-ready implementation
} Identify and handle edge cases for Pagination. What happens under high load, with invalid input, or during failures?
Solution
// Edge case handling:
// 1. Null/empty input -> validation
// 2. High load -> rate limiting, queuing
// 3. Failures -> retries, circuit breaker
// 4. Concurrent access -> locks, idempotency Write a testing strategy for Pagination. Include unit tests, integration tests, and performance tests.
Solution
// Test plan:
// - Unit: 80% coverage target
// - Integration: API contracts
// - Performance: latency, throughput
// - Chaos: failure injection Quiz
1. Which pagination type degrades performance at high offsets?
2. For a social media feed, which pagination is best?
3. What is a common mistake when implementing Pagination?
Flashcards
Question
Offset vs cursor pagination?
Click to reveal answer
Answer
Offset: page number, can jump. Cursor: consistent, can't jump.
Question
When to use cursor pagination?
Click to reveal answer
Answer
Large datasets, real-time feeds, streaming
Question
Pagination best practices
Click to reveal answer
Answer
Follow SOLID principles, write clean code, test thoroughly, document decisions, and monitor in production.
Revision Notes
Key Takeaways
- 1. Offset-based: simple but degrades at high offsets
- 2. Cursor-based: consistent and performant, can't jump to page
- 3. Choose based on use case: admin panels=offset, feeds=cursor
- 4. Always include total count or hasMore flag
Interview Tips
- • Compare offset vs cursor pagination
- • Know when to use each type
Cheat Sheet
Pagination
- Offset:
?page=2&limit=20(simple, degrades) - Cursor:
?cursor=abc&limit=20(consistent, performant) - SQL Offset:
LIMIT 20 OFFSET 20 - SQL Cursor:
WHERE id > 123 LIMIT 20 - Admin panels: Offset, Feeds: Cursor