30% offEnding soon
FSD-015Frontend system design Premium

Design an Infinite Scroller

Design a resilient infinite scroller with cursor pagination, stable viewport anchoring, restoration, bounded prefetch, and accessible recovery states.

Intermediate 52 min read

Treat infinite scrolling as a paginated collection with a convenient trigger. The trigger may be automatic, but cursor ownership, item identity, viewport position, and recovery remain explicit.

An infinite scroller looks simple in a demo. Put a sentinel under the last card, observe it, and fetch another page. Production behavior is harder. A slow response can arrive after the user changes filters. A repeated record can appear on adjacent pages. An image above the viewport can decode and move the reader. Browser Back can return to a pixel offset before the old data window exists.

The system needs two separate notions of progress. The cursor tells the server where the current query continues. A stable item ID tells the client what the reader is looking at. Neither can safely replace the other.

Start with the collection contract

Model the list as normalized items, an ordered ID sequence, a page ledger, and a query generation. Each page records its input cursor, returned cursor, status, and item IDs. The request layer owns cancellation and single-flight rules. The viewport layer owns the visible anchor and restoration checkpoint.

An Intersection Observer is useful for noticing proximity to the end. It is not the state machine. Its callback can run more than once, the sentinel can remain visible after an append, and layout changes can cross the threshold again. Route every observation through one guarded loadNext() command.

The public interview prompt

Design an infinite scroller for an activity feed, search results, or product catalog. Explain:

  • cursor pagination, deterministic ordering, stable tie breakers, and opaque continuation tokens;
  • query generations, request cancellation, single-flight ownership, and stale responses;
  • ordered merges, duplicate IDs, updated records, deletions, and empty pages;
  • sentinel observation, prefetch distance, network evidence, and backpressure;
  • loading, retry, offline, exhausted, permission-changed, and partial states;
  • stable viewport anchoring during append, prepend, media decode, and live insertion;
  • browser Back restoration, deep links, saved checkpoints, and missing anchors;
  • explicit Load more controls, focus, announcements, footer reachability, and SEO paths;
  • pagination versus virtualization, memory budgets, cache eviction, and long sessions;
  • analytics, performance measurements, testing, rollout, and fallback behavior.

Assume the collection contains millions of records, pages normally contain 25 items, records may be inserted or deleted while the reader is present, and item heights vary after media loads. These numbers are interview assumptions, not measured product facts.

What the premium solution covers

The full solution builds the page and request state machines, defines safe cursor merges, derives a measured prefetch policy, preserves a stable visual anchor, restores a route after the data window has been evicted, and keeps loading failures operable.

Original media traces one request from sentinel observation through an ordered append, separates the collection's state rails, shows a durable restoration checkpoint, and visualizes a bounded prefetch envelope. Two deterministic labs let readers provoke stale and duplicate pages, then calculate an anchor correction after content above the viewport changes.

Premium solution

Continue with the complete system design

Unlock the architecture, state machine, API contracts, original diagrams, positioning model, accessibility decisions, performance budgets, testing plan, rollout strategy, scoring rubric, and interview walkthrough.

  • Detailed, beginner-friendly explanation
  • Production failure modes and trade-offs
  • Mobile-friendly architecture diagrams
  • Senior and staff-level interview signals
Unlock Premium

Frequently asked questions

Should an infinite scroller use cursor or offset pagination?
Prefer an opaque cursor when the collection can change while someone is reading. A cursor can encode the server's ordering boundary without asking the client to infer it from a numeric offset. The server still needs a deterministic sort with a stable tie breaker.
When should the next page load?
Observe a sentinel near the end and schedule one request when it enters a measured prefetch margin. The margin should reflect observed latency and scroll speed. It must not bypass single-flight, visibility, query-generation, or terminal-state guards.
How do you preserve scroll position when items change above the viewport?
Capture the first stable visible item ID and its offset from the viewport. After the mutation, find that item again and adjust scrollTop by the change in its measured offset. Reserve media dimensions to avoid avoidable corrections.
How should browser back restoration work?
Store a query fingerprint, anchor item ID, anchor offset, and enough cursor checkpoints to rebuild the data window. Restore only after the anchor item is present and measured. Fall back to the nearest surviving item when the exact anchor no longer exists.
Does infinite loading remove the need for virtualization?
No. Pagination controls how much data is fetched, while virtualization controls how many rows are mounted. A long session can fetch many pages and still create an expensive DOM unless a separate windowing layer bounds rendering.
How can infinite scrolling remain accessible?
Expose a real Load more control, keep loading and retry states in document order, announce concise result counts, preserve focus, and provide a path to the footer. Automatic loading should enhance that explicit control rather than replace it.