Your order list now has pagination - with page and limit, which is called offset pagination. On small data it runs fine. But when data is in the hundreds of thousands, and someone asks for page 5000 - then the database has to count off the first 100 thousand rows and throw them away before giving the next 20. The deeper the page, the slower the work. Not only that, if a new order gets added in the middle, the page math shifts and the same order can appear on two pages.
Cursor pagination - starting from the last seen place
In the cursor shape there is no page number - there is a marker: 'give from after the id I saw last'. The database can start directly from that place holding onto the index - speed stays the same even on deep pages, and the math does not shift even if new data arrives in the middle. Social feeds, chat history, big lists - this is the usual shape everywhere. The price is: you cannot jump to any page, you can only move forward or backward.
// offset - simple, enough for small data
GET /orders?page=3&limit=20
// cursor - for big, changing data
GET /orders?cursor=order_9821&limit=20
SELECT * FROM orders WHERE id > 9821 ORDER BY id LIMIT 20;Which one you pick depends on the use. In an admin panel you need to go to a specific page and the data is medium-sized - offset is good. Customer-facing feeds or long lists - cursor. In interviews, being able to say 'when which' is where the real marks are.
Logging - production's eyes
When something breaks in production, you are not sitting beside the server. Then the only reliance is the log - which request came, where the error happened, how long it took. If you scatter console.log around, you cannot find it; keep structured logs with a proper logger (like pino or winston) - time, request id, endpoint, status. If a unique request id stays in every log, you can trace a request's whole journey. And be careful: never write passwords or tokens in logs.
The mistake everyone makes
Two mistakes: blindly using offset pagination on huge data to build a slow API, and reaching production to realize there are no useful logs at all - then catching a bug means groping in the dark. Logging is not a hobby thing, it is a precondition for running production.
Today's practice
Add cursor pagination to your order list alongside offset. Then compare how the two behave - add a new order in the middle and verify for yourself whether the repetition that happens in offset happens in cursor. Along with that, put a logger in place and log every request.
How to say it in an interview
For small or admin-type data, offset pagination is enough, but for big and changing data I take cursor pagination - because it lets you start directly holding the index even on deep pages, speed does not drop, and the list does not shift when new data arrives. In production I keep structured logs with request ids, so that when there is a problem the whole journey can be found.