Pagination across shards (Medium interview post)
A stub. The article is a Medium member-only story and the body could not be read — WebFetch returned the preamble, and a Firecrawl scrape returned the same paywall page. Recorded per the hub’s edge rule rather than dropped, with everything below limited to what the public preview shows.
Umesh Kumar Yadav, August 2026, tagged Java / Software Development / Software Engineering / Programming / Database.
What the preview establishes
The framing question, quoted:
Your order table contains hundreds of millions of records, spread across multiple database shards. A user wants to open page 100,000. How would you design the pagination?
And the anti-pattern it starts from:
SELECT * FROM orders ORDER BY create_time DESC LIMIT 1000000, 10;described as “one of the slowest ways to retrieve data.” The preview says the question tests database internals, index design, distributed systems, sharding and performance optimization. The subtitle — “The Interview Question That Separates Senior Engineers from Architects” — places the genre: interview preparation, not engineering documentation.
What it does not establish
Everything that matters. The comparison of offset against keyset/cursor pagination, why OFFSET
degrades (the engine must still walk and discard the skipped rows), how a scatter-gather across
shards merges and re-sorts partial pages, how a cursor is encoded to stay stable across shards, and
what any of it costs — all behind the wall. No claim about the solution should be attributed to
this page.
Why it is kept anyway
It names a gap this spoke already had. database-sharding describes the proxy router’s job as
“aggregate results from multi-shard queries back into one answer” in a single bullet, and
planetscale-768-servers presents 768 servers behind one hostname without saying what an
ORDER BY … LIMIT costs once the rows live on 256 shards. Deep pagination is the sharpest ordinary
case of that aggregation problem: the router cannot know which shard holds rows 1,000,000–1,000,010
without asking all of them for their first 1,000,010.
So the question is well-posed and the corpus can’t answer it yet. Logged as an open question in synthesis.
Substitute source pulled, same day. vitess-query-serving-docs was read at the human’s
instruction to answer the question this stub couldn’t: cross-shard-queries now records the
mechanism (push down what the shard key routes, scatter and merge at the proxy when it doesn’t, so
a deep offset makes every shard return offset+limit rows) and the instrument (VEXPLAIN TRACE
reports ShardsQueried). What is still missing, and would still make this article worth reading:
a cost model for deep offsets and an explicit keyset/cursor recommendation. Neither appears in
the Vitess pages read.
T4 — paywalled, unread, single-author interview-prep content with no editor and no cited sources. Even read in full it would not be an authority; the value here is the question, not the answer. Partly resolved 2026-08-03 by the Vitess documentation route (see above). A friend link would still add the article’s own comparison of offset against keyset pagination, which no source here has.
Related
database-sharding · cross-shard-queries · vitess-query-serving-docs · planetscale-768-servers · operational-databases · synthesis