DRF cache_page URL-only caching behavior with authenticated PageNumberPagination responses

Django REST Framework's cache_page decorator caches responses by URL alone, without regard to the authenticated user or query parameters such as page_size. When combined with PageNumberPagination—which defaults to 100 items and clamps to max_page_size—this raises an unresolved design tension: the same URL can represent different data slices and different user contexts, yet the cache key remains identical.

DRF does not provide a built-in mechanism to invalidate cached responses when a model instance changes, nor does the decorator incorporate request headers or user identity into the cache key. Developers are left to choose between manual cache clearing via signals or accepting potential staleness. The interaction becomes sharper when large page_size values are permitted, because a single cached response may contain a substantial payload that is then reused across unrelated requests.

Is there a documented, supported pattern for scoping cache_page to authenticated DRF views without risking cross-user data leakage? Should cache invalidation on model updates be handled entirely outside DRF, or does the framework offer any hook for paginated endpoints? What is the recommended trade-off between max_page_size limits and cache reusability when responses are cached by URL only?