Spring Boot Pagination with Pageable, Page, and Slice

🔍 What Is It?

Spring pagination in Spring Boot is the pattern used to split large result sets into manageable API responses. If you search for "Spring Boot pagination," the direct answer is that Pageable, Page<T>, and Slice<T> are the main abstractions used to request and return paginated data, most often through Spring Data JPA.

Quick Facts

• →Used in: REST list endpoints, admin dashboards, search results, and mobile infinite-scroll APIs
• →Best for: Returning large datasets safely without unbounded memory or payload growth
• →Interview importance: High because pagination is a common Spring Data and API design topic
• →Production relevance: High because list endpoints break down quickly without paging rules
• →Related topics: Spring Data JPA, repositories, entity mapping, controllers

Core abstractions

• →Pageable - the request object with page number, size, and sort
• →Page<T> - the response object with content, total count, and pagination metadata
• →Slice<T> - a lighter response that skips the total count query and only tells you whether another page exists

Common pagination details

• →Page numbers are 0-indexed by default
• →Sort rules can be passed through request params or created in code
• →PageRequest.of(page, size, sort) is the standard programmatic constructor

🎯 Why Do We Need It?

Without pagination, list endpoints return too much data, create slow database queries, and make API consumers harder to support. Pagination is one of the first production protections every serious backend should implement.

Interview Relevance

• →Interviewers ask pagination to test whether you understand API design, database load, and Spring Data behavior
• →Strong answers explain Page versus Slice, max page size enforcement, and why deep offset pagination becomes expensive
• →Senior answers usually connect pagination to indexing, sorting, and client-specific UX patterns such as infinite scroll

🏗️ What Happens in Real Projects?

Production Usage

Pagination is used on nearly every bounded list endpoint:

• →GET /api/v1/orders?page=0&size=20&sort=createdAt,desc
• →GET /api/v1/products?category=electronics&page=0&size=50
• →Admin dashboards showing paginated tables
• →Mobile apps using infinite scroll with Slice

Teams also use pagination rules to enforce fair API usage, prevent oversized responses, and keep database queries predictable as tables grow.

⚙️ How It Works

With Spring Data JPA, a paged repository query applies an offset and a maximum result size; the JPA provider translates that into database-specific paging syntax. A Page<T> may need an additional count query for total elements and total pages. Spring Data can omit that count when it can infer the total from the returned data. A Slice<T> typically fetches one extra row to check whether another slice exists without calculating a full total.

Pageable vs Page vs Slice

• →Pageable describes the incoming request: page number, page size, and sort
• →Page<T> returns content plus total count metadata
• →Slice<T> returns content plus only enough information to know whether another page exists

Stable sorting and input limits

Always sort deterministically. If several records share createdAt, add a unique tie-breaker such as id. Reject negative pages and non-positive sizes, cap the maximum size, and allow only supported sort properties. Offset pagination can still shift when rows are inserted or removed; keyset pagination is a better fit for deep, changing feeds.

💻 Example

Pagination in Practice — Repository, service, and controller with full pagination support.

// Repository
public interface OrderRepository extends JpaRepository<Order, Long> {
    Page<Order> findByCustomerIdAndStatus(
        Long customerId, OrderStatus status, Pageable pageable);

    // Slice for infinite scroll (no COUNT query)
    Slice<Order> findByStatus(OrderStatus status, Pageable pageable);
}

// Service
@Service
@Transactional(readOnly = true)
public class OrderService {

    public Page<OrderSummaryDto> getCustomerOrders(
            Long customerId, OrderStatus status, int page, int size, String sortBy) {

        if (page < 0 || size < 1) {
            throw new ResponseStatusException(HttpStatus.BAD_REQUEST, "Invalid page or size");
        }
        if (!Set.of("createdAt", "id").contains(sortBy)) {
            throw new ResponseStatusException(HttpStatus.BAD_REQUEST, "Unsupported sort property");
        }
        int validSize = Math.min(size, 100);
        Sort sort = Sort.by(Sort.Direction.DESC, sortBy);
        if (!"id".equals(sortBy)) {
            sort = sort.and(Sort.by(Sort.Direction.DESC, "id"));
        }
        Pageable pageable = PageRequest.of(page, validSize, sort);

        return orderRepository
            .findByCustomerIdAndStatus(customerId, status, pageable)
            .map(OrderSummaryDto::from);
    }
}

// Controller
@GetMapping
public ResponseEntity<Page<OrderSummaryDto>> getOrders(
        @RequestParam(name = "page", defaultValue = "0") int page,
        @RequestParam(name = "size", defaultValue = "20") int size,
        @RequestParam(name = "sortBy", defaultValue = "createdAt") String sortBy,
        @RequestParam(name = "status", defaultValue = "PENDING") OrderStatus status,
        @AuthenticationPrincipal UserDetails user) {

    Page<OrderSummaryDto> orders = orderService.getCustomerOrders(
        userService.getIdByUsername(user.getUsername()), status, page, size, sortBy);

    return ResponseEntity.ok(orders);
}

🤔 Common Confusions

🚨 Common Production Issues

✅ Best Practices

🏛️ Architect's Note

💬 Frequently Asked Questions

🎯 Key Takeaways

🔗 Related Topics

🎯 Practice this topic in interviews

↗ Where this topic fits