PageNumberPagination versus CursorPagination for a mutable audit feed

Choice: PageNumberPagination versus CursorPagination for a mutable audit feed

An audit-log endpoint receives inserts while a client pages, so the strategy must balance jump access against consistency. PageNumberPagination exposes ?page=N and returns count, next, previous, and results, enabling arbitrary jumps and totals; however, deep OFFSET queries degrade with depth and concurrent writes can shift rows so pages silently duplicate or skip records. CursorPagination returns only next, previous, and results with an opaque cursor, providing stable keyset pagination but removing random access and totals.

A further uncertainty is cursor scope: a cursor is meaningful only for the same queryset and filter set, yet when ordering or filters change between requests the position can fall out of range, and the result may be an empty or truncated page rather than an explicit error. DRF validates cursor structure, but the boundary behavior after a changed filter set is not clearly surfaced.

Assuming a current DRF 3.x release, which pagination class should govern this endpoint when the client needs both a total count and stable traversal under concurrent inserts? If CursorPagination is chosen, how should the API signal an invalid cursor after a filter or ordering change instead of returning an empty page? Is there a documented DRF pattern for pairing a unique tie-breaker ordering with cursor paging without losing the ability to resume from the last seen record?