Wie würdest du einen Endpoint mit einer großen Collection paginieren, und warum nicht einfach limit und offset?

Nimm bevorzugt Keyset-Pagination, auch Cursor-Pagination genannt: sortier nach einem stabilen, eindeutigen Key, gib einen opaken Cursor für die letzte Zeile zurück und frag nach den Zeilen danach. Offset-Pagination zwingt die Datenbank, jede übersprungene Zeile zu lesen und wegzuwerfen, Seite fünftausend ist also langsam, und Zeilen, die mitten im Scrollen eingefügt oder gelöscht werden, erzeugen Duplikate und Lücken. Keyset bleibt pro Seite konstant teuer und ist stabil unter Writes.

Mein Default ist Keyset. Der Client fragt eine Seite an, bekommt Items plus einen opaken Cursor zurück, und der nächste Request sagt gib mir die Zeilen nach diesem Cursor. Darunter ist das eine where-Klausel auf dem Sortierschlüssel, mit dem richtigen Index also ein Index Seek, und die Kosten sind auf Seite eins dieselben wie auf Seite tausend. Offset kann das nicht, weil die Datenbank weiterhin alles vor dem Offset durchläuft und wegwirft, und schlimmer noch: wird beim Scrollen eine Zeile eingefügt, verschiebt sich jede folgende Seite, und die Person sieht ein Duplikat oder verpasst ein Item komplett. Das Detail, über das Leute stolpern, ist der Tiebreaker: sortiere ich nach created_at und zwei Zeilen teilen sich einen Timestamp, ist die Reihenfolge nicht deterministisch, der Cursor kodiert also created_at plus die id, und der Vergleich läuft über das Paar. Aufgeben muss ich beliebige Seitensprünge und billige Gesamtzahlen. Bei einem Infinite-Scroll-Feed vermisst die niemand; bei einer Admin-Tabelle, die Seitenzahlen braucht, nehme ich Offset mit einem begrenzten Maximum.