How we build
the feed that never
ends

Infinite scroll works best when you barely notice it. You flick your thumb, more posts appear, and you keep going. No "Next Page" button. No long pause. The feed simply flows.

That seamlessness is the product. A blank gap, a jump, or a visible wait breaks the experience. So the real goal is not simply "show more posts." It is this:

Make an endless stream of content feel continuous while the backend fetches, ranks, and renders each new batch.

To do that, the app requests the next batch before you reach the bottom. The backend must decide which posts belong in your feed, preserve their order, and return them quickly enough that the next batch is ready before you need it.

We will start with the simplest implementation, see exactly where it fails, and then replace it with a design that works for a live production feed.

Imagine every post lives in a giant list in the database, newest at the top. When you open the app, we hand you the first 20. You scroll to the bottom, and we say to the database: "skip the 20 you already sent, give me the next 20." Scroll again: "skip 40, give me 20."

This has a name. It's called offset pagination, and it's the first thing almost everyone reaches for. In database language it looks like this:

It's clean. It's easy to understand. You could even build old school numbered pages and jump straight to page 50. For a small app, it works fine.

And then your app gets popular. And it quietly starts to die.

When you say "skip 100,000 rows," the database still has to locate and discard those 100,000 rows before it can return the next 20. OFFSET does not identify a stable starting row. It only describes how many rows must be ignored in the current sorted result.

This is why latency grows with scroll depth. The red bars show an illustrative offset query as the skipped row count increases. The teal bar shows the cursor approach we will build next, where the query starts from a known sort key instead of recounting from the beginning.

By page 5,000, the example offset query is over 600 times slower than the cursor query. The exact numbers depend on the database, the index, and the data, but the pattern is what matters. Offset work grows with the number of skipped rows. The cursor keeps the starting point explicit, so the teal bar stays nearly flat at any depth.

Speed isn't even the worst of it. There's a second crack, and it's the kind that makes users think your app is broken.

Picture this. You have just read posts A through T, the first 20 rows in the feed. While you are reading, five new posts are inserted at the top. That is normal on a live feed. When you scroll again, the app still asks for "OFFSET 20, then return the next 20."

The offset did exactly what we asked. It skipped the first 20 positions in the new version of the list. But those positions no longer contain the same 20 posts. The five new rows moved A through T down by five places, so the next page begins at P instead of U. The user sees P through T twice.

We now have two failures from the same design. Deep offsets are expensive, and moving positions make pagination inconsistent. Both problems come from using a changing position as the continuation point.

Both failures come from using a changing position as continuation state. "OFFSET 20" means "start at position 21 in the list as it exists now." If rows are inserted or deleted, position 21 can refer to a different post.

A cursor stores the sort key of the last row returned. For a feed ordered by created_at DESC, id DESC, the cursor can contain the last post's created_at and id. The next request asks for rows that come after that exact key in the same ordering.

That changes the API from "skip 20 rows" to "continue after this row." The continuation point is tied to a stable value from the result set, not to a position that can move.

Now we can build the query and see how the cursor fixes both problems.

Instead of "skip 20," the app now hands the server the bookmark from the last post it received. The server turns that into a plain, honest question to the database: "give me the posts that come after this exact one."

The important part is the WHERE clause. With an index that matches the ordering, for example (created_at DESC, id DESC), the database can seek to the cursor key and scan only the next 20 index entries. It does not need to count and discard every row before the cursor.

Crack #1, sealed. The query begins at the cursor key instead of scanning through every earlier result. Page 5 and page 50,000 perform roughly the same amount of page work.

Crack #2, sealed too. New posts at the top do not change the cursor key. The next request continues after the last row the user actually received, so inserts above it do not move the continuation point.

Why not use only the post ID?

The cursor must represent the same ordering used by the query. Here the feed is ordered by created_at DESC, id DESC, so the cursor carries both values.

You can use only the ID when the feed itself is ordered by ID and those IDs are strictly monotonic. But many systems use UUIDs, random IDs, or an order that does not match ID order. In those cases, the ID alone does not tell the database where the row belongs in the feed.

In this query, created_at preserves the recency order. The id makes that order unique when two posts have the same timestamp. Together they create a deterministic sort order, so the next page cannot lose or repeat rows at the boundary.

We also hide the bookmark

The API normally returns an opaque cursor instead of exposing separate database fields. A simple implementation can serialize the values to JSON, encode them with Base64URL, and optionally attach an HMAC signature. The encoding keeps the client independent of the cursor schema. The signature lets the backend reject a modified cursor. Base64URL by itself is not encryption.

And one clever shortcut: "grab one extra"

How does the app know when to stop, when there is nothing left to load? Counting every remaining post would be expensive. So if the app wants 20 posts, the backend asks the database for 21. If 21 rows come back, there is another page. The backend returns 20 items and sets hasNextPage to true. If 20 or fewer rows come back, it returns them and sets hasNextPage to false.

A fast, stable backend is only half the promise. The other half lives on your screen. And screens have their own breaking point: they choke when asked to hold too much at once.

If you scrolled for twenty minutes and the app kept every post you passed, your phone would be trying to draw tens of thousands of items at once. The browser grinds, scrolling gets choppy, memory balloons, and eventually the whole thing crashes.

The fix: only draw what fits on the glass

Here's the sleight of hand. At any moment, only about 20 posts actually fit on your screen. So why keep the other 9,980 drawn? We don't. The app draws only the handful you can see, plus a small buffer just outside the viewport so nothing flickers. As you scroll, it recycles those same item components and binds them to new post data.

To keep the scrollbar honest, the app uses an invisible spacer as tall as all the posts would be. It feels like thousands of items are present, but only a small window of components is mounted at any time. This technique is called virtualization, or "windowing," because the UI renders only the moving window around the current viewport.

The last enemy: the jump

You've felt this one. You go to tap something, an image finishes loading, everything lurches down, and you tap the wrong thing. That lurch is called a layout shift, and it's the fastest way to make an app feel cheap.

The defense is preparation. Before a post's image arrives, the app reserves the exact space it will need, often showing a grey skeleton placeholder in the meantime. It also fetches the next batch early, while you are still a screen or two away from the bottom, so the new posts are ready by the time you arrive. Done right, the seam is invisible. The entire handoff finishes before the user notices it.

Everything so far is the foundation, and every large feed builds on the same core ideas. At the scale of hundreds of millions of people, platforms add more machinery to decide not just where the feed continues, but what deserves to be in it at all. Here is the high level shape of each approach.

Notice the shared foundation under all three. They precompute what they can, assemble the rest on demand, rank candidates in stages, and use a stable pagination contract to continue the feed.