API Pagination Interview Questions: Cursors, Consistency, and Rate Limits

API pagination questions are really questions about a changing collection. Offset pagination is easy to explain but can skip or duplicate rows when inserts and deletes occur. Cursor pagination anchors the next request to a position or sort key, yet it still needs a stable ordering, an expiration policy, and a rate-limit strategy. Stripe's documentation is a concrete example of cursor parameters and auto-pagination; the interview value is in explaining what your API promises when data changes between calls.

Start with PracHub interview questions to practice the underlying skill while this article explains the named platform, workflow, or engineering topic. PracHub questions are practice material; they are not claims about a private employer question bank.

Quick answer

Read this article in three layers. An official provider or employer source establishes what the product or process says. A candidate report can suggest a useful preparation drill, but it does not prove that every candidate sees the same configuration. The final layer is an inference: a tactic that follows from the evidence. Keeping those layers separate prevents a familiar platform name from turning into an invented universal rule.

Offset versus cursor semantics

Offset pagination maps a page number to a query position. Under concurrent writes, a new row near the front can shift every later row, causing duplicates or skips. Cursor pagination instead encodes a position in an ordered sequence. It reduces drift when the ordering is stable, but it does not magically create a database snapshot. A good answer names whether the API promises a consistent snapshot, best-effort traversal, or results that may change between requests.

Designing an opaque cursor

A cursor can encode the last sort key, a unique tie breaker, a tenant scope, a schema version, and an expiry timestamp, then be signed or otherwise protected from tampering. Keep it opaque to clients so the server can evolve the representation. Validate that the cursor belongs to the same filter and principal. If the sort key is not unique, add a deterministic secondary key; otherwise two rows with the same timestamp can be skipped or repeated.

Consistency and retries

A client can retry a page after a timeout without knowing whether the server completed it. The API should make repeated cursor requests safe to read and should document whether items can appear twice across pages. For stronger consistency, use a snapshot token or a database transaction boundary, but explain the storage and lifetime cost. For high-volume feeds, a monotonic event ID or time-plus-ID cursor may be enough if the consumer deduplicates by resource ID.

Rate limits and backpressure

Pagination amplifies request volume. Expose a sensible default and maximum page size, return rate-limit headers or a documented error, and let clients back off with jitter. Auto-pagination helpers should stop on context cancellation and preserve the last cursor for resume. A server should not make a huge page the only way to avoid rate limits; it should balance payload size, database work, and fairness across tenants.

Deletes, updates, and mutable filters

A row can be deleted between pages, or an update can move it earlier in the sort order. Decide whether the endpoint is a snapshot, a change feed, or a best-effort listing. Do not promise exactly-once traversal unless you can support it. For synchronization APIs, use a high-water mark, tombstones, and a stable change sequence. For user-facing lists, clear freshness language is often more useful than an expensive global snapshot.

Observability and compatibility

Log the endpoint, tenant, cursor version, page size, query duration, rows returned, and rate-limit response without logging sensitive cursor contents. Test invalid, expired, cross-filter, empty, and last-page cursors. Document that a next cursor may be absent or null. A strong interview answer includes a migration path when the sort key or cursor format changes, because clients may hold cursors longer than the server release cycle.

Practice with five verified PracHub questions

Use these complete PracHub question titles as deliberate practice. Work once under a timer, then repeat while narrating the invariant, the failure mode, and the trade-off. The links build transferable skill; they do not imply that the named company or platform will reuse the prompt.

A focused preparation and recovery plan

Frequently asked questions

Is cursor pagination always consistent?

No. It reduces offset drift, but consistency depends on the ordering and snapshot contract.

What belongs in a cursor?

A stable sort position, unique tie breaker, scope or filter binding, version, and optional expiry—usually encoded opaquely.

How do you avoid duplicates?

Use deterministic ordering, a tie breaker, and client or server deduplication appropriate to the contract.

Should APIs expose total counts?

Only when the cost and freshness meaning are clear; a count can be expensive or stale.

How should clients handle a rate limit?

Honor the documented retry signal, back off with jitter, and resume from the last confirmed cursor.

Before you start

Turn the article into a small decision record before you act. Write the exact question you need to answer, the source that could answer it, and the consequence of being wrong. For an assessment, that might be whether the timer stops, whether a second display is allowed, or whether a previous result can be reused. For a technical interview, it might be whether the system promises per-key ordering, whether the verifier can prove a loop is bounded, or whether a cache update can be replayed. This framing keeps preparation tied to the target rather than to a list of fashionable keywords.

Next, separate hard constraints from choices. A deadline, access rule, memory limit, privacy boundary, or source-of-truth requirement is a constraint. A page size, data structure, model pair, retry policy, or practice order is a choice that you should justify. Write one default choice, one alternative, and the signal that would make you switch. Interviewers and recruiters can then see judgment instead of a memorized answer.

Finally, decide what evidence will close the loop. Save a confirmation, a source position, a benchmark row, a test result, a metric, or a recovery ticket. Do not collect private assessment content or credentials. The evidence should be sufficient for the next person to reproduce the decision without exposing information they are not authorized to see. If the evidence is missing, label the conclusion provisional and ask the owner for the exact next action. That discipline is useful whether the page is about a hiring platform, a production system, or a candidate-reported study.

A final quality check is simple: remove any claim that depends on an unnamed company policy, an undated forum anecdote, or a number whose denominator you cannot explain. Replace it with the narrower fact, the verification step, or the limitation. Readers usually need a safe next move more than a confident-sounding prediction. That editorial boundary also makes the draft easier to update when a platform changes its controls or a new hiring cycle starts. Use the same discipline for every source and every handoff.

How to decide what to trust

The live invitation and the instructions shown inside the assessment outrank a generic article. The provider's current help center explains default product behavior, but employers can choose different question types, timers, proctoring controls, report fields, or deadlines. An official employer page establishes the published role or event context; it does not establish every team's interview sequence. Candidate reports are useful when they identify the role, date, and product, yet they remain samples. When two sources disagree, record the conflict instead of averaging it into a made-up number. If a technical incident is involved, preserve the state first, then use the platform's support route or the recruiter who owns the invitation. This approach is slower than guessing, but it gives the reader an action that can be defended and repeated.

Final takeaway

Treat pagination as a consistency contract, not a loop around offset += limit. Define ordering, cursor lifetime, retries, mutations, and rate-limit behavior before choosing the encoding.

Sources and Further Reading

• Stripe pagination
• Stripe API pagination reference
• Stripe rate limits
• RFC 8288 Web Linking

Research note: Sources checked 2026-09-06. Platform settings, recruiting schedules, and technical documentation can change; verify the exact invitation or current release before acting.