advanced 1 min answer

An image discovery application does heavy infinite scrolling with per-user recommendations. What should the client data layer provide?

client-cachingpaginationinvalidationmemorypinterest
Show the full answer Hide the answer

The requirements this workload creates

  • Cursor-based pagination, not offset. Content shifts constantly as new items are inserted, so an offset-based page two shows items already seen or skips items entirely. This is a correctness issue that presents as a user-experience complaint.
  • Normalised entity caching, so an item appearing in several feeds is stored once and updates consistently. Denormalised caches produce the same item showing different states in two places on screen.
  • Bounded memory with eviction. An infinite scroll session accumulates thousands of items and their images; without windowing and eviction the tab is eventually killed, particularly on mobile.
  • Virtualised rendering, so DOM node count stays bounded regardless of how far the user has scrolled.
  • Optimistic updates for saves and follows, since these are frequent, low-risk and feel broken with a round-trip delay.
  • Deduplicated in-flight requests, because scroll and resize handlers otherwise fire the same fetch several times.

The invalidation question

Personalised feeds go stale in a way generic content does not. A recommendation computed for a user twenty minutes ago is less relevant than one computed now, but refetching the whole feed loses scroll position and the user's place.

The workable answer is stale-while-revalidate on the pages already loaded, with fresh content only for pages not yet fetched — the user's current view stays stable and new content improves as they scroll.

The measurement

Scroll smoothness and memory on a mid-range mobile device. Both degrade gradually with session length, so a short test on a fast device shows nothing. The failures here are found by long sessions, not by page loads.