Your API returns 10 million orders.

The frontend asks for "page 5."

Offset 40, limit 10. Simple enough — until your DBA messages you at 2 AM.

Query time: 4.2 seconds. Table scans climbing. Prod is lagging.

Here's the stack: PostgreSQL, 50M rows in orders, sorted by created_at DESC. Users can filter by status. You're paginating an admin dashboard used by 200 concurrent support agents.

Offset pagination worked fine at 10K rows. At 50M, it's reading and discarding 40 million rows just to return 10.

You need to fix this before the next sprint ships the customer-facing version — which will have 10x the traffic.

Here's your setup:

• Table: orders — 50M rows, indexed on created_at, user_id, status

• Query: sorted by created_at DESC, filtered by status

• Client: needs "previous/next" navigation + jump-to-page

• SLA: p99 < 200ms

Four engineers propose four different approaches:

A) Cursor pagination — encode the last seen created_at + id into a token, use it as a WHERE clause anchor

B) Keyset pagination…