Which pagination strategy should NestJS services expose for large datasets when UI requires page numbers but data volume may grow beyond offset limits?

Goal: determine the pagination approach to expose through a NestJS REST endpoint that serves a large table while keeping response latency acceptable and UI able to show page numbers.

Constraints: offset‑based (skip/take) is easy to map to page numbers but degrades on deep pages; cursor‑based pagination offers constant cost but requires a stable, unique ordering and does not directly give total count or page indexes, making UI pagination harder. The team must also consider concurrent writes and the version‑specific APIs of TypeORM or Prisma in use.

Questions: Which strategy better balances UI page‑number expectations with scalability for datasets expected to exceed one million rows? How can a NestJS service layer provide an estimated total count or page‑number mapping when using cursor‑based pagination without sacrificing the performance benefits?