Spring Data Cassandra paging state: continue the same bounded query

Keep the query fixed

A parcel timeline endpoint returns one partition in small batches. Spring Data Cassandra can carry a driver paging state or CassandraScrollPosition into the next request. The token belongs to the original statement and its parameters. If tenant, parcel, filters or page size change, discard it and start again. The partition key remains mandatory.

Treat the token as opaque

Do not decode a paging state into an offset or expose it as proof of authorization. Bind it to the authenticated tenant and query fingerprint in your API layer, and set an expiry. Concurrent writes can affect later pages; if the product needs a fixed historical view, materialize a snapshot or choose a cutoff and test its semantics.

Probe discontinuity

Read one page, insert an event, then request the next page. Assert the API's documented ordering and duplicate handling. Also replay a token under a different tenant and require rejection before any database call.

Implementation sketch

Query pageQuery = Query.query(
    Criteria.where("tenant_id").is(tenantId)
        .and("parcel_id").is(parcelId))
    .limit(47);
// A validated CassandraScrollPosition may be attached for continuation.

Cost and verification

Each page limits response memory, but a client can still walk a large partition. Apply a request budget and avoid counting all rows just to display a page number.

Common Mistakes

• Do not represent a paging state as an integer offset.
• Do not reuse a token with different query parameters.
• Do not trust a token to authorize access to a tenant's data.

Read next

Spring Data Cassandra partition keys: model the read before the row, Spring Data Cassandra TTL: expiry is a storage and query cost, Spring JWT tenant claims: reject missing or malformed ownership before conversion.

Related boundary

Spring Data Cassandra consistency: budget availability and staleness per operation