Loading...
Loading...
Browse 4 real-world technical and behavioral interview questions about Pagination. Review scenarios, edge cases, and architectural best practices.
Size it first: 200M daily actives opening the feed six times a day is 42k reads/s at peak, while 100M posts fanned out to 200 followers each is 231k feed writes/s, so writes dominate. Push to ordinary accounts, pull for high-follower ones, and store ids so deletes and blocks filter on read.
The server holds one row per message, partitioned by conversation and clustered by descending sequence so a page is a contiguous read, and clients page by keyset cursor rather than offset. Per-user state moves to a side table so the body stays shared, and if messages are end-to-end encrypted the wipe is a key-custody question, not a storage one.
Model resources around client workflows, paginate with an opaque keyset cursor because offset pagination skips and duplicates rows under concurrent writes, make unsafe operations replayable with a client-supplied idempotency key, and evolve additively so that versioning stays a last resort rather than a routine.
Offset pagination gets slower with depth and drifts when rows are inserted mid-traversal, so paginate with a keyset comparison on the sort key plus a unique tiebreaker, hand back an opaque cursor and a Link rel=next header, and price an exact total count separately.