Design a Mobile Paging Library

This page is one interview loop in three rounds. All three rounds design the same system. Each round opens with the interviewer raising the scope, and the design from the round before has to evolve to meet it.

In this loop the "system" is mostly a library that runs on the phone, plus the paging API behind it. That makes API and library design as important as infrastructure: what the server promises about order and cursors decides whether the phone can ever get the list right. How the phone keeps a local database, syncs changes and caches images is the subject of the offline-first news feed loop; how a server builds and ranks a feed is the news feed loop. We link to both instead of teaching them again.

You can start at any round. Rounds 2 and 3 open with a "Where we left off" summary that catches you up.

Loop Opener: What Is a Paging Library?

You Already Use One: a Conveyor Belt That Only Loads What's Near You

Picture a sushi conveyor belt in a restaurant with a million dishes in the kitchen. The belt in front of you holds only a few dozen plates. As you eat your way along, the kitchen puts new plates on just ahead of you, and plates far behind you go back to the kitchen. It feels endless, but the table never holds more than a few dozen plates.

A paging library does the same for a list on a phone. The list looks endless, but the app keeps only a small window of items in memory, fetches the next page (a fixed-size batch, say 20 items) just before you need it, and drops items far away from what you're looking at.

What Makes It Hard

• People fling fast. A hard fling on a phone moves thousands of pixels a second. A fetch has to start early enough to finish before the user gets there.
• The list changes underneath. New items arrive at the top while you read, and old ones get deleted. A naive "page 3" then repeats or skips items.
• Phones have small memory and tight frame budgets. A cheap phone has little RAM to spare, and at 120 Hz the app has 8.33 ms to produce each frame.
• A page must never skip or repeat. A repeated item looks like a bug, and on some UI toolkits a repeated ID crashes the app. A skipped item is silently lost.

The Question the Whole Loop Answers

How do we make an endless list feel instant and stable while holding only a little of it?

The answer gets sharper every round:

• Round 1: the server pages by position in a total order (a cursor), never by count, and the phone only builds views for what's on screen.
• Round 2: the phone's database is the single source of truth: the network fills it, the list reads from it, a bounded window lives in memory, and every change reaches the screen as a diff computed off the main thread.
• Round 3: the paging logic becomes a product with a contract: pluggable data sources, ranked-feed sessions, in-place updates, accessibility, telemetry and a release process that can't break 20 teams.

---

Round 1 · Mid-level · "An Infinite List That Doesn't Skip or Repeat"

~35 min · SDE II (L5) · 1 region, 3 AZs · 1M DAU · ~347 page requests/s peak · mid-range phones

R1.1 Establish Design Scope

The interviewer says: "Our marketplace app has a 'New listings' screen. It shows a page of 20 and a 'Load more' button, and users hate it. Make it an infinite list." We ask before we draw.

Out of scope for this round: new items appearing at the top while reading, offline use, memory limits for very long sessions, and velocity-aware prefetch.

R1.2 Functional Requirements, Derived Step by Step

Not yet: loading newer items at the top (prepend), offline reading, and prefetch that adapts to scroll speed.

R1.3 Non-Functional Requirements: the Questions

Numbers come in R1.7. For now, the questions and why each matters:

• Smoothness. A 60 Hz display draws a frame every $1000 \div 60 \approx 16.7$ ms; a 120 Hz display every $1000 \div 120 \approx 8.33$ ms. The main thread (the one thread that draws the UI and handles touches) must finish its share of each frame inside that budget, or the user sees a stutter, called jank. Where may network calls, JSON parsing and view creation run?
• Correctness. What exactly does "no duplicates, no gaps" mean when the list is changing? We'll define it as: every listing that existed for the whole scroll appears exactly once. Listings posted after the user started scrolling appear on the next refresh, not in the middle of their scroll.
• Memory. How many views and items may exist at once? A phone doesn't give an app much, and the OS kills apps that use too much.
• Data use. Many users pay per gigabyte. How many bytes does a page cost, and how many pages do we fetch that nobody sees?
• Server cost. Does a request for page 5,000 cost the same as page 1?

R1.4 The API

One endpoint. It returns a page of items and a cursor: a token that means "continue after this item".

First page:

httpCopy
GET /v1/items?limit=20 HTTP/1.1
Host: api.example-market.com
Authorization: Bearer <token>
Accept-Encoding: gzip

httpCopy
HTTP/1.1 200 OK
Content-Type: application/json
Content-Encoding: gzip

{
  "items": [
    {
      "item_id": "731829301994475520",
      "title": "Road bike, 54 cm frame",
      "price": { "amount_cents": 42000, "currency": "USD" },
      "seller": { "id": "90412", "name": "Ana's Bikes" },
      "thumb": { "id": "tq81", "w": 720, "h": 720 },
      "created_at_us": 1790596800123456
    }
  ],
  "next_cursor": "eyJ2IjoxLCJsIjoibmV3IiwidHMiOjE3OTA1OTY3OTc0MTAyMDEsImlkIjoiNzMxODI5MjAyMTE4MTA2NDk2In0.pG7vQ2",
  "has_more": true
}

Next page: send the cursor back exactly as received.

httpCopy
GET /v1/items?limit=20&cursor=eyJ2IjoxLCJsIjoibmV3IiwidHMiOjE3OTA1OTY3OTc0MTAyMDEsImlkIjoiNzMxODI5MjAyMTE4MTA2NDk2In0.pG7vQ2 HTTP/1.1
Host: api.example-market.com
Authorization: Bearer <token>

What's inside the cursor. It is base64url(JSON) + "." + signature. Decoded, the JSON part is:

jsonCopy
{
  "v": 1,
  "l": "new",
  "ts": 1790596797410201,
  "id": "731829202118106496"
}

• ts and id are the sort key of the last item on the page (its creation time in microseconds, and its ID). The next page means "items that sort after this pair".
• v is a format version and l names the list, so one cursor can't be replayed against another list.
• The signature is an HMAC (a keyed hash only the server can produce) over the JSON. It is a signature, not encryption: anyone can base64-decode the cursor, so it must hold nothing secret.

Why opaque? The client stores the cursor and sends it back; it never builds, reads or edits one.

1. We can change what's inside (add a field, change the sort) without breaking app versions already on phones. Old cursors are recognized by v.
2. Clients can't craft cursors to scan the table, jump to arbitrary positions, or reach a list they shouldn't. A bad signature gets 400.
3. The order stays the server's business. If the client built "after (ts, id)" itself, the sort rule would be frozen into every app version.

Two precision details that matter:

• ts is in microseconds, the precision PostgreSQL's timestamptz stores. A cursor rounded to milliseconds would compare against a value that doesn't exist, and listings created in the same millisecond just after the rounded value would be skipped.
• IDs are strings in JSON. Our IDs are 64-bit numbers; JavaScript and many JSON parsers hold integers exactly only up to $2^{53}$, so a 64-bit ID sent as a JSON number can be silently rounded. ts in microseconds is about $1.79 \times 10^{15}$, below $2^{53} \approx 9.0 \times 10^{15}$, so it is safe as a number.

Recap

• One call: GET /v1/items?cursor=&limit=20, returning items, next_cursor and has_more.
• The cursor is opaque and signed; decoded, it is the last item's (created_at, item_id).
• The server never counts rows to find a page.

Let's build it, starting with the simplest thing that works.

R1.5 Design Evolution: From "Page Numbers" to Keyset Cursors and Recycled Views

Every step below follows the same pattern: a problem, your turn to think, the answer, and what the answer costs us. The cost is usually the next problem.

Step 1.0: The Baseline

The app asks for ?page=5. The server turns that into an offset: skip the first 80 rows, return the next 20. The app keeps every loaded item in a list and creates a view for each.

sqlCopy
SELECT item_id, title, price_cents, created_at
FROM listing
WHERE status = 'active'
ORDER BY created_at DESC
LIMIT 20 OFFSET 80;   -- page 5

Synthesizing vector architecture diagram...

The page number becomes a row count. Notice that nothing in the request says which listing the user saw last.

What's good about it: it is simple, and "jump to page 50" is easy.

What it costs us: an offset is a count of rows, and the count changes whenever a row is added or removed above it. The database also has to walk past every skipped row.

Step 1.1: Page 2 Repeats Items From Page 1

Primitives: Database Isolation Levels & Concurrency Anomalies (each page is a separate query with its own snapshot, which is why offsets drift) · Distributed Unique ID Generators (the unique tie-breaker)

Step 1.2: Deep Pages Are Slow

Step 1.3: Scrolling a Long List Uses Lots of Memory

Step 1.4: The Next Page Loads Too Late

Step 1.5: Parsing Freezes the UI

Round 1 Step Summary

Two costs stay open for Round 2: loaded item data still grows without limit, and nothing works offline.

R1.6 Architecture v1

Now the pieces get platform and AWS names.

Synthesizing vector architecture diagram...

Follow a scroll: the list tells the controller "I'm near the end", the controller asks the network data source for the page after the stored cursor, and the answer comes back ready to insert. On the server, every page is one keyset query on an Aurora reader.

The pieces:

• Paging controller (on the phone): holds the loaded items, the next cursor and the load state (idle, loading, error, end). It decides when to fetch and makes sure only one fetch per cursor is in flight.
• Network data source: turns "load after cursor X" into an HTTP call, decodes on a background thread, and returns items plus the next cursor.
• Items API on ECS (Fargate) behind an Application Load Balancer in three AZs. It checks the cursor's signature, runs the keyset query, builds the next cursor from the 20th row, and uses the 21st row only to set has_more.
• Aurora PostgreSQL: a writer (sellers' inserts and updates) and a reader in another AZ for the list queries. Aurora readers share the cluster's storage volume, so a reader sees committed writes after a short replica lag, typically well under a second.

The server schema:

sqlCopy
CREATE TABLE listing (
    item_id      BIGINT PRIMARY KEY,                               -- 64-bit, time-ordered ID
    created_at   TIMESTAMPTZ NOT NULL DEFAULT clock_timestamp(),   -- database clock, microseconds
    title        VARCHAR(200) NOT NULL,
    price_cents  BIGINT NOT NULL,
    currency     CHAR(3) NOT NULL,
    seller_id    BIGINT NOT NULL,
    thumb_id     VARCHAR(32),
    status       VARCHAR(16) NOT NULL DEFAULT 'active'             -- active, sold, removed
);

CREATE INDEX listing_newest
    ON listing (created_at DESC, item_id DESC)
    WHERE status = 'active';

The phone's state (in memory this round):

Trace 1: the first page.

Synthesizing vector architecture diagram...

The 21st row is never shown; it only proves there is more.

Trace 2: the next page, prefetched.

Synthesizing vector architecture diagram...

Trace 3: an error and a retry.

Synthesizing vector architecture diagram...

A retry repeats the same cursor, so it can't skip or repeat anything: a page request is a read, and reading twice is harmless.

R1.7 Numbers

Traffic (assumptions: 10 page requests per user per day; peak is 3× the average)

Payload (assumptions: about 1 KB of JSON per listing with its seller and thumbnail metadata, so 20 KB per page before compression; gzip shrinks repetitive JSON to about 40%; thumbnails come from a CDN and are counted separately)

Database (assumptions: 20M active listings of about 2 KB each; a keyset seek costs well under 1 ms of CPU when the index and hot rows are in memory)

A db.r7g.large (2 vCPUs, 16 GiB) reader holds the whole index in memory and runs a few hundred simple indexed queries a second with most of its CPU idle.

Fleet (assumption, to confirm by load test: one 1 vCPU / 2 GB task serves about 350 requests a second)

Peak need is $347 \div 350 = 1$ task. We run one per AZ, 3 in all, so losing an AZ leaves 2.

Monthly cost (us-east-1 on-demand list prices, rounded; other regions list higher)

Say the headline: at this scale the database instances are almost half the bill, and a keyset query costs the same at page 1 and page 5,000. With offsets, a crawler walking to page 5,000 would make each request scan 100,000 index entries, and we'd need a far bigger database for the same traffic.

R1.8 Trade-Offs

R1.9 Failure Modes

R1.10 Pillar Check

R1.11 Round 1 Rubric and Follow-Ups

What a strong mid-level (L5) answer shows

• Explains, with an example, why offsets repeat and skip items when rows are inserted or deleted.
• Designs a keyset cursor with a unique tie-breaker, writes the query and the matching index, and knows the seek is $O(\log N)$ at any depth.
• Makes the cursor opaque and signed, and can say why.
• Uses view recycling and keeps bind cheap.
• Sizes the prefetch distance from fetch time and scroll speed, and keeps only one request per cursor in flight.
• Keeps network, decode and formatting off the main thread and knows the 16.7 ms and 8.33 ms budgets.

Follow-up questions

1. "Product wants a 'page 3 of 50' indicator. What do you say?" Answer: a total count means counting millions of active rows on every request, and it's wrong a second later as listings come and go. For a changing list we show "Showing newest listings" and, if they need orientation, a date divider. If product truly needs counts, an approximate count maintained by a background job is fine for display, but pages still use cursors.

2. "Why not use item_id alone as the cursor? It's time-ordered." Answer: we could, if item_id is generated in time order and the list is always "newest first". Then item_id < cursor is a total order on its own. We kept (created_at, item_id) because the same pattern works when the sort column isn't the ID (a "recently updated" list, or a price sort, where the ID is only the tie-breaker). Either way, the rule is the same: the cursor must hold every column of a total order.

3. "The user sorts by price. What changes?" Answer: a new index (price_cents, item_id) and a cursor holding the last row's price and ID. Price can change while someone scrolls; a listing whose price drops below the cursor after they passed it won't be seen, and one whose price rises past it may be seen twice. For a marketplace that's acceptable, and the client drops a repeated item_id. Round 3 comes back to sort keys that move.

Interview gotchas from this round's wrong answers

---

Round 2 · Senior · "Both Directions, Offline, and 120 Hz Smooth"

~40 min · Senior SDE (L6) · 1 region, 3 AZs · 50M DAU · ~20.8K page requests/s and ~8.7K head checks/s at peak · keyset seek < 5 ms P99 · < 30 MB of paging memory on low-end phones · 8.33 ms frames

R2.0 Where We Left Off

This is what the candidate says aloud in the first 60 seconds of Round 2. If you're starting here, it's everything you need from Round 1.

Round 1 in 60 seconds. "We turned a 'Load more' button into an infinite list for 1M daily users, about 347 page requests a second at peak. Offsets repeat and skip items when rows are added or removed, and they get slower with depth, so we page with a keyset cursor: the last item's (created_at, item_id), where the unique ID breaks ties, signed and opaque to the client. The server seeks a composite B-tree index, WHERE (created_at, item_id) < cursor ORDER BY created_at DESC, item_id DESC LIMIT 21, which costs the same at any depth; the 21st row only sets has_more. On the phone we use a recycling list, keep bind cheap, prefetch one page (20 items) ahead, allow one request per cursor, and do network and decoding off the main thread. About $0.9K a month. Two costs are open: loaded items grow without limit, and nothing works offline."

Architecture v1, compact

Synthesizing vector architecture diagram...

Round 1 in one picture: the list asks, the controller fetches the page after the cursor, and the server seeks an index.

Round 1 step summary

Open costs: unbounded item memory; no offline use.

R2.1 The Scope Raise

Interviewer: "We're now a social app with 50 million daily users, and the list is a feed of posts in topics people follow. New posts appear at the top while people read further down. Pull-to-refresh must not throw them back to the top or make the list jump. The feed must open and scroll offline from what we saved. People fling at thousands of pixels a second on 120 Hz phones, and our low-end Android phones must stay under about 30 MB for the whole list, even after someone scrolls through 10,000 posts."

A scope raise is not the end of scoping. We ask back, and say what each answer changes.

Scope change

R2.2 What Breaks in the Round 1 Design

R2.3 New Requirements and API Additions

1. Paging in both directions. Each list is addressed by ID. A request without a cursor returns the head (the newest page). A cursor plus a direction walks older or newer.

httpCopy
GET /v1/lists/40117/items?limit=20 HTTP/1.1
Host: api.example-social.com
Authorization: Bearer <token>
Accept-Encoding: gzip

httpCopy
HTTP/1.1 200 OK
Content-Type: application/json
Content-Encoding: gzip
ETag: "hv-7Qm2"

{
  "items": [
    {
      "item_id": "731902214477398016",
      "sort_ts_us": 1790596790042113,
      "version": 3,
      "author": { "id": "5520", "name": "Kim Lee" },
      "text": "Trail report: the north loop is open again...",
      "thumb": { "id": "pX4a", "w": 1200, "h": 675 },
      "like_count": 214,
      "comment_count": 18
    }
  ],
  "newer_cursor": "eyJ2IjoyLCJsIjo0MDExNywiZCI6Im4iLCJ0cyI6MTc5MDU5Njc5MDA0MjExMywiaWQiOiI3MzE5MDIyMTQ0NzczOTgwMTYifQ.Hq2w",
  "older_cursor": "eyJ2IjoyLCJsIjo0MDExNywiZCI6Im8iLCJ0cyI6MTc5MDU5NjcxMTgwNDQ1MCwiaWQiOiI3MzE5MDE4ODI2MDM5ODMyMzIifQ.a8Lk",
  "has_newer": false,
  "has_older": true
}

httpCopy
GET /v1/lists/40117/items?dir=older&limit=20&cursor=eyJ2IjoyLCJsIjo0MDExNywiZCI6Im8i...a8Lk HTTP/1.1
GET /v1/lists/40117/items?dir=newer&limit=20&cursor=eyJ2IjoyLCJsIjo0MDExNywiZCI6Im4i...Hq2w HTTP/1.1

Decoded, a v2 cursor names its list and its direction, so a cursor can't be used for another list or walked the wrong way:

jsonCopy
{ "v": 2, "l": 40117, "d": "o", "ts": 1790596711804450, "id": "731901882603983232" }

The server contract that makes this correct:

Why the settle window. created_at is stamped with the database clock when the row is inserted, but the row only becomes visible when its transaction commits, and our reads go to an Aurora reader a little behind the writer. So a post stamped at 12:00:00.100 could become visible after a post stamped 12:00:00.300 was already served as the head. A phone whose newest cursor is the 12:00:00.300 post asks for "newer than that" and doesn't see the 12:00:00.100 one. We bound both delays, per request, rather than trusting an alarm:

• Commit delay. A post is written by a single-statement INSERT (autocommit), so the gap from clock_timestamp() to commit is capped by statement_timeout = 1 s. Multi-statement posting paths set transaction_timeout = 1s (PostgreSQL 17+).
• Replica lag, measured. Each service task polls its reader's lag every second (aurora_replica_status(), column replica_lag_in_msec) and uses $\text{cutoff} = \text{now} - (1 \text{ s} + \text{observed lag} + 0.5 \text{ s margin})$ for head and newer reads. With normal lag well under 100 ms, that's about 1.5 s.
• Lag unknown or above 5 s: head and newer reads go to the writer, where lag is zero and the cutoff is now − 1.5 s.
• The replica-lag alarm stays, but only to page a human; correctness never depends on someone answering it.

Within the cutoff, everything has committed and is visible on the reader that serves the request. An empty newer response therefore means "nothing settled yet", not "nothing ever": the next head check re-checks. The cost is that a new post appears in feeds about 1.5 seconds late.

2. A cheap head check. To show the "New posts" pill, the phone asks whether the head changed, with the head's ETag. Nearly all answers are 304 Not Modified with no body.

httpCopy
GET /v1/lists/40117/head HTTP/1.1
If-None-Match: "hv-7Qm2"

httpCopy
HTTP/1.1 200 OK
ETag: "hv-8Bx9"
Content-Type: application/json

{ "newest": { "item_id": "731903001234567168", "sort_ts_us": 1790596902113007 } }

The phone checks every 120 s, only while the list is on screen and the app is in the foreground. R2.6 sizes this rate; it's almost half as many requests as page loads.

3. Paging states, one per direction. The library keeps three independent load states: refresh, prepend and append. The UI shows a spinner or a retry row at the matching edge, and a refresh spinner at the top.

Synthesizing vector architecture diagram...

One of these runs for each direction. A refresh cancels the other two and blocks them until it finishes: the same priority rule Paging 3's RemoteMediator applies; its default LAUNCH_INITIAL_REFRESH also holds prepend and append until the first refresh succeeds.

4. Placeholders. A placeholder is an empty slot for an item we know exists but haven't loaded into memory. The list keeps its full length, so the scrollbar is honest and rows don't shift when a page loads or is dropped. The row draws a grey skeleton until the item arrives. We know the counts because they come from the phone's database, not the server.

The library's settings, next to Jetpack Paging 3's PagingConfig defaults:

R2.4 Design Evolution: Database-Mediated Paging, a Bounded Window and Smooth Updates

Step 2.1: Offline, and Network Results Flicker In

Deeper background on the local database (WAL mode, transactions, schema migrations): the offline-first news feed loop, steps 1.1 and 1.3 and Round 3.

Step 2.2: Memory Grows Without Limit

Primitive: Distributed Cache Patterns & Eviction (the same "evict what's farthest from use" idea, applied to a window)

Step 2.3: The List Jumps When New Items Are Added at the Top

Step 2.4: Pull-to-Refresh Races With Loading More

Step 2.5: A Fast Fling Fires 20 Requests

Primitive: API Protocols: HTTP/1.1 vs HTTP/2 vs HTTP/3 & gRPC (streams and per-stream cancellation)

Step 2.6: Rows Flicker, Animate Wrongly, or Crash

Round 2 Step Summary

R2.5 Architecture v2

Synthesizing vector architecture diagram...

Read it right to left for data and left to right for requests. Nothing reaches the list UI except through the database, the window and the diff. The mediator is the only part that talks to the network, and it only writes to the database.

The pieces:

• The library on the phone: the remote mediator (states per direction, the generation fence, scroll-speed sensing, coalescing), SQLite as the source of truth, the memory window of 200 items with placeholders, and the background diff that feeds the list.
• Paging service on ECS (Fargate) behind an ALB: verifies cursors (signature, version, list, direction), runs keyset queries, applies the settle window, builds both cursors per page, answers head checks with ETags.
• Aurora PostgreSQL: one writer for new posts and edits, and three readers, one per AZ. Each service task reads from the reader in its own AZ through that instance's endpoint and falls back to the cluster reader endpoint if it's down. The cluster reader endpoint alone spreads connections across readers regardless of AZ, so about two thirds of result bytes would cross AZs.
• ElastiCache for Valkey: caches each topic's serialized head page (with its ETag) for 2 seconds; one primary and two replicas, one per AZ, and each task reads its own AZ's node.
• CloudFront, only for shared lists. A topic's head page is the same for everyone, so it could be cached at the edge. A personalized page (a home feed built for one user) can't be: every user's page differs, and caching it by user would add risk and no hits. R2.6 shows why we leave CloudFront off the default path and keep it for a public list that goes viral.

The server schema:

sqlCopy
CREATE TABLE post (
    item_id     BIGINT PRIMARY KEY,
    list_id     BIGINT NOT NULL,                                  -- the topic
    created_at  TIMESTAMPTZ NOT NULL DEFAULT clock_timestamp(),   -- database clock, microseconds
    version     INTEGER NOT NULL DEFAULT 1,                       -- bumped by every edit
    author_id   BIGINT NOT NULL,
    body        TEXT NOT NULL,
    thumb_id    VARCHAR(32),
    status      VARCHAR(16) NOT NULL DEFAULT 'visible'            -- visible, deleted, hidden
);

CREATE INDEX post_list_order
    ON post (list_id, created_at DESC, item_id DESC)
    WHERE status = 'visible';

The three queries, all on post_list_order (the newer one scans it backward). statement_timestamp() is fixed for the statement, so the cutoff can be an index condition; clock_timestamp() changes row by row and can't:

sqlCopy
-- head
SELECT ... FROM post
WHERE list_id = $1 AND status = 'visible'
  AND created_at < statement_timestamp() - $2::interval   -- $2 = 1 s + observed lag + 0.5 s
ORDER BY created_at DESC, item_id DESC LIMIT 21;

-- dir=older
SELECT ... FROM post
WHERE list_id = $1 AND status = 'visible'
  AND (created_at, item_id) < ($2, $3)
ORDER BY created_at DESC, item_id DESC LIMIT 21;

-- dir=newer: the 21 nearest above the cursor, returned to the phone newest first
SELECT ... FROM post
WHERE list_id = $1 AND status = 'visible'
  AND (created_at, item_id) > ($2, $3)
  AND created_at < statement_timestamp() - $4::interval   -- the same adaptive cutoff
ORDER BY created_at ASC, item_id ASC LIMIT 21;

Go deeper: the head cache. Heads are read far more than any other page of a topic: every open, every refresh, and every head check whose ETag doesn't match. The service keeps a topic's serialized head page in Valkey for 2 seconds.

• A miss is filled once. Within a task, concurrent misses for the same topic wait on one in-flight query (single-flight), and the fill is written with SET ... NX EX 2, so a slower filler can't overwrite a fresher one. If the cache restarts empty, the first wave of misses is at most one query per topic per task, not one per request, and the readers are sized to absorb every head uncached (R2.6).
• Why not cache the head for longer, or forever? The head changes whenever someone posts; a head cached for an hour hides an hour of posts. A 2 s TTL bounds staleness to 2 s on top of the ~1.5 s settle window, and edits bump the ETag because it's computed from the IDs and versions on the page. Deeper pages change too (edits, deletes), and their hit rate would be low anyway, since cursors differ between readers.

These are the two questions of the hot product page drill.

Trace 1: a fling toward older posts.

Synthesizing vector architecture diagram...

The duplicate trigger joins the running load, and one request of 60 replaces a chain of three.

Trace 2: new posts arrive while the user reads.

Synthesizing vector architecture diagram...

The overlap test compares sort keys, so it passes even if our old newest post was deleted.

Trace 3: scrolling offline.

Synthesizing vector architecture diagram...

Nothing in this trace touches the network except the one append at the end of the saved run, and its failure is a footer, not an error screen.

How a fling looks over time (a 15,000 px/s fling with 300 px rows is 50 rows a second; the mediator's planned fetch time is 1 s):

Synthesizing vector architecture diagram...

R2.6 Numbers and Cost

Traffic (the interviewer's figures; peak is 3× the average)

Head checks (assumption: the feed is on screen about 10 minutes a day, in the foreground; one check per 120 s while it is)

A check every 30 s would be 1B a day and 34.7K/s at peak, more than all page requests together. The rate is a design decision we size, not a detail. (The ALB's default idle timeout is 60 s, so a check every 120 s usually opens a new connection; that's in the ALB line below as new connections, which stay well under the bytes dimension.)

Bytes on the wire (≤ 25 KB per 20-post page after gzip; we plan with 25 KB as the average, so this is an upper bound; requests are about 0.5 KB with HTTP/2 header compression; a head check answer is about 0.5 KB)

On the phone

The fetch time we plan prefetch with (p95 on 4G, warm connection; each figure an assumption to check against field telemetry)

The main-thread budget. At 120 Hz the frame is 8.33 ms, and the system's rendering needs part of it; we give the app's main thread about half, ~4 ms, for binding, layout and applying diff results. At 15,000 px/s a 300 px row enters every $300 \div 15{,}000 = 20$ ms, about every 2.4 frames, so one bind must fit comfortably in ~4 ms. That is why bind only sets fields and hands the image URL to the loader.

Database (assumptions, to confirm by load test: a keyset seek returning 21 rows costs about 0.4 ms of CPU when the index and hot rows are cached, so ~2,500 seeks a second per vCPU; the three-year catalog is 500M posts)

Fleet (assumptions: a 2 vCPU / 4 GB task serves ~700 page requests a second; a head check costs a quarter of a page; every fleet must carry the peak with one AZ lost, and we round per AZ)

Monthly cost (us-east-1 on-demand list prices, rounded; tiers are list prices, and other regions list higher)

Four notes on that table:

• Bytes are the bill. Data transfer out is 63% of it. The cheapest page is one not fetched: initialLoadSize 40 instead of 60, and one page of prefetch instead of three when reading.
• Why readers in the tasks' own AZ. A seek returns 21 rows of about 2 KB each, about 42 KB: 450M seeks a day × 42 KB × 30.4 ≈ 575 TB a month. Through the cluster reader endpoint, about two thirds would cross AZs at $0.02/GB: ≈ $7.7K a month for nothing.
• Why not API Gateway or CloudFront in front of the API. At 18.24B page requests a month, API Gateway's HTTP API list price ($1.00 per million for the first 300M, $0.90 after) is about $16.4K, four times the ALB's $3.8K. CloudFront's request fee alone ($0.01 per 10,000 HTTPS requests in the US) would be about $18.2K, more than the edge saves on bytes. CloudFront earns its place only for a shared list so hot that edge hits save the origin real work.
• Aurora I/O. AWS suggests Aurora I/O-Optimized when I/O is more than about a quarter of the Aurora bill. Our I/O budget is about $2K of $5.3K (38%), over AWS's 25% guideline. At these numbers I/O-Optimized would cost about 4 × $1.44/h × 730 + 1 TB × $0.225 ≈ $4.4K, saving about $0.9K a month (assumptions: I/O-Optimized instances about 30% above Standard, storage $0.225/GB-month). We start on Standard only because $2K is a budget, not a measurement, and switch once a month of real I/O confirms it.

That's about $0.00085 per daily user per month, and delivery is most of it.

R2.7 Trade-Offs

R2.8 Failure Modes

R2.9 Production Gotchas

R2.10 Pillar Check

R2.11 Round 2 Rubric and Follow-Ups

What a senior (L6) answer adds over L5

• Makes the local database the single source of truth and explains the remote mediator's job, including invalidation and how the scroll position survives it.
• Bounds memory with a window, placeholders and reloads, and does the memory arithmetic, with images as the real budget.
• Designs prepend on the server as "nearest first" and handles late commits with a settle window.
• Keeps the anchor still on inserts and diffs off the main thread, citing a real cost.
• Fences refresh races with a persisted generation checked inside each write, and merges on refresh by comparing sort keys.
• Coalesces loads, adapts prefetch to velocity, and cancels flown-past work.
• Derives traffic, head-check rates, bytes, fleets with an AZ lost, and a cost dominated by bytes.

Follow-up questions

1. "Why not just use Paging 3's defaults?" Answer: they're a good start, but two matter at scale: maxSize defaults to unbounded, so without setting it memory grows with the session; and initialLoadSize defaults to three pages, which at our traffic is data many users never see. Prefetch that changes with velocity isn't built in, so we add it around the Pager.

2. "The user rotates the phone, or the OS kills the app in the background. What survives?" Answer: the database holds the items, cursors, generation and the anchor item's ID. On recreation, the list loads the window around that anchor from SQLite and shows it with no network call. SKIP_INITIAL_REFRESH applies if the saved data is fresh, so we don't refresh just because the process restarted.

3. "A post is edited while it's on screen. What happens?" Answer: this round, the edit shows up when a page containing it is reloaded from the network (a refresh overlapping it, or a head load): its higher version updates the row in place, and the diff reports a change, not a move. Edits far down a long list can be stale for a while. Round 3 adds an update channel.

Interview gotchas from this round's wrong answers

---

Round 3 · Architect · "One Library for Every Team, Platform and Feed Type"

~45 min · Principal (L7) · 1 region, 3 AZs for our backends · 80M DAU · 2.4B list-page loads/day across 20 teams (≈ 83K/s at peak), 960M of them on our feed backend · iOS, Android and web · per-device-class budgets

R3.0 Where We Left Off

This is what the candidate says aloud in the first 60 seconds of Round 3. If you're starting here, it's everything you need from Rounds 1 and 2.

Rounds 1 and 2 in 60 seconds. "We page by keyset cursor, the last item's (created_at, item_id), signed and opaque, so inserts and deletes never repeat or skip items and a deep page costs one index seek. In Round 2 the feed became 50M daily users, 600M pages a day, about 20.8K requests a second at peak. The phone's SQLite database is the single source of truth: a remote mediator writes pages and their edge cursors in one transaction, keeping the saved items one contiguous run, and the list reads a window of at most 200 items around the user, with placeholders for the rest and reloads from SQLite. Diffs run off the main thread and the anchor item stays still on inserts; new posts wait behind a 'New posts' pill found by a head check every 120 s. Refresh bumps a persisted generation that every write re-checks, and merges by comparing sort keys. The server walks newer pages nearest first and serves only posts older than a settle cutoff of 1 s plus measured replica lag plus 0.5 s, about 1.5 s, reading from the writer if lag is unknown or over 5 s. Low-end phones stay at about 25 MB of paging memory; frames are 8.33 ms. About $42.3K a month, 63% of it data transfer. Open costs: it's built for one app and one backend, edits far from the top go stale, and we can't see how it behaves in the field."

Architecture v2, compact

Synthesizing vector architecture diagram...

Round 2 in one picture: the network writes the database, and the list only ever reads it.

Round 2 step summary

Open costs: tied to one API and one schema; no in-place updates for items off the top; no accessibility design; no versioning or telemetry.

R3.1 The Scope Raise

Interviewer: "Twenty teams want your library: chat history, search results, the ranked home feed, order history, settings lists. We ship on iOS, Android and the web. The ranked feed reorders between requests. Items get edited and deleted while people look at them. Screen-reader users must be able to use every list. And whatever you ship, you can't break twenty teams' apps."

Scope change

R3.2 What Breaks in the Round 2 Design

R3.3 New Requirements and API Additions

1. The data-source contract. Teams implement one operation; the library owns everything else (the database cache, the window, diffing, states, prefetch, retries). It's a contract, not code: inputs, outputs and rules.

This deliberately mirrors Paging 3's PagingSource (LoadParams.Refresh, Append, Prepend; LoadResult.Page, Error, Invalid), so Android teams recognize it, while the spec stays platform-neutral for iOS and web.

2. Ranked-feed cursors. For ranked lists, the server stores the ranked order for a session, and the cursor points into it:

jsonCopy
{ "v": 3, "m": "ranked", "sid": "fs_8k2Q", "o": 40 }

A cursor for an expired session returns:

httpCopy
HTTP/1.1 410 Gone
Content-Type: application/json

{ "error": "SESSION_EXPIRED", "action": "refresh" }

3. The item-update channel.

4. Accessibility behaviours (step 3.4): announce loading, errors and "N new items"; never move focus on inserts; expose position and set size; offer "load more" and jump controls.

5. Telemetry hooks (step 3.6): the library emits named events (first page shown, frame hitch, load error, duplicate dropped, overlap failed, memory high-water); the app forwards them to its telemetry pipeline, aggregated per install per day.

R3.4 Design Evolution: A Contract, Sessions, Updates, Access, Stability, Telemetry

Step 3.1: Every Team Has a Different Backend

Step 3.2: Ranked Feeds Reorder Between Pages

Step 3.3: An Item Was Edited or Deleted While on Screen

Step 3.4: Screen Readers Get Lost in Endless Lists

Step 3.5: Library Updates Break Teams

Go deeper: testing a paging library.

• Unit tests with a scripted fake data source: it serves a list that changes between calls, and the test asserts the correctness rule from Round 1: every item that existed for the whole scroll appears exactly once, for random sequences of loads, inserts, deletes, refreshes and drops. Android's paging-testing artifact (TestPager, asSnapshot) runs a real Pager against such a fake.
• Race tests: pause a response, start a refresh, release the response, and assert the generation fence rejects it. Kill the process mid-transaction and assert the run is still contiguous on restart.
• Frame tests on real low-end devices: Macrobenchmark's FrameTimingMetric on Android, XCTest's scroll performance metrics on iOS, with a fling script, tracked per release.
• Network conditioning: slow 3G, packet loss and airplane mode during a load.
• Accessibility passes with TalkBack, VoiceOver and a keyboard-only web run.

Step 3.6: Is Paging Healthy Across Apps?

Round 3 Step Summary

R3.5 Global Architecture

The library, per platform. One written spec and a shared set of test vectors; three native implementations with the same layers.

Synthesizing vector architecture diagram...

Teams write only the top box of the middle panel. The same layers run on each platform; what differs is the UI adapter at the bottom and the storage underneath the cache.

Platform notes:

• Android: built on Jetpack Paging 3 (Pager, Room PagingSource, RemoteMediator, PagingDataAdapter or LazyPagingItems), wrapped with our contract, velocity-aware prefetch and validation.
• iOS: our own implementation: SQLite through GRDB or Core Data, an observation feeding a diffable data source, UICollectionViewDataSourcePrefetching for early image loads, and offset compensation on inserts above the viewport.
• Web: the same contract over IndexedDB (database mode) or memory; a virtualized list that renders only the visible rows; an IntersectionObserver on a sentinel row as the prefetch trigger; a page limit in the query cache (for example TanStack Query's maxPages for infinite queries) as the window; CSS scroll anchoring (overflow-anchor, which MDN marks as Baseline 2026, so older browsers lack it), and the same offset compensation as iOS where it's missing.

The backends and pipelines behind it.

Synthesizing vector architecture diagram...

The library talks to many backends, but only through the data sources teams wrote. Our own backends are the feed paging service, the ranking-session store the feed service uses, and the telemetry pipeline.

Trace 1: a ranked feed across three pages, with an expiry.

Synthesizing vector architecture diagram...

Pages 2 and 3 read a frozen list, so they can't repeat or skip; after expiry the library appends a new session below the reader instead of jumping.

Trace 2: an edit while the item is visible.

Synthesizing vector architecture diagram...

A late copy of version 3 arriving afterwards changes nothing, because the stored version is already 4.

R3.6 Numbers and Cost

Memory budgets per device class (assumptions to validate against the memory high-water and OOM telemetry; detected at start-up from total RAM, Android's isLowRamDevice() and memory class, and on iOS from physical memory plus os_proc_available_memory() for live headroom)

Every maxSize stays at or above pageSize + 2 × prefetchDistance = 140.

Load across all teams (the interviewer's figures; peak 3× average)

Defaults are capacity. About 800M list opens a day (10 per user). For lists whose data source fetches initialLoadSize from the network (network mode, and refreshes that use it), if a library release moved initialLoadSize from our 40 to Paging 3's default of 60, each open would load 20 more items, about 25 KB: $800\text{M} \times 25 \text{ KB} = 20$ TB a day, about 608 TB a month more egress across the teams' backends, roughly $30K a month at the $0.05/GB tier, plus their database reads. A default is a capacity decision for 20 backends at once.

Feed backend (Round 2's per-request assumptions; head checks now 80M × 5 = 400M a day, ≈ 13.9K/s at peak)

Ranking sessions (assumptions: 3 ranked sessions per user per day; 500 IDs of 8 bytes each, stored as one packed string per session; 30-minute expiry after the last read; peak 3× average)

Telemetry (one ~2 KB daily summary per active install; 1% of installs add ~50 KB of traces)

Quota check. A Firehose stream with Direct PUT in us-east-1 defaults to 5 MiB/s (with 2,000 requests/s and 500,000 records/s). Our peak of about 6.6 MiB/s is over it. We split the stream by platform: three streams at about 2.2 MiB/s each, well under the default, and we confirm the quotas before launch. The collector batches records with PutRecordBatch, which keeps us far under the request limit but doesn't change bytes per second.

Monthly cost (us-east-1 on-demand list prices, rounded; other regions list higher)

Aurora I/O, again. The I/O budget is about $3.0K of $8.8K of Aurora spend (34%), over AWS's 25% guideline. I/O-Optimized would cost about 7 × $1.44/h × 730 + 1 TB × $0.225 ≈ $7.6K, saving about $1.2K a month (assumptions: instances about 30% above Standard, storage $0.225/GB-month). As in Round 2, we start on Standard because $3.0K is a budget, not a measurement, and switch once a month of real I/O confirms it.

Delivery is still more than half the bill (57%). The line the library team controls most is the one not in the table: the defaults that set how much 20 teams' backends send (above).

R3.7 Trade-Offs

Closing the loop. The question was how to make an endless list feel instant and stable while holding only a little of it. Round 1 answered "page by position in a total order, and build views only for what's visible". Round 2 answered "make the phone's database the single source, keep a bounded window, and apply every change as a diff that keeps the reader's place". Round 3's answer is that the list is only as correct as the contract under it: stable identities, keys that make progress, orders that don't move during a session, and a library that checks all three and tells us when they break.

R3.8 Failure Modes

R3.9 Runbook and Incident Response

Golden signals, per library version, app, platform and device class OPS 8 · OPS 4

Library rollback procedure OPS 6 · REL 8

1. Confirm it's the library. Compare the signal between apps on the new version and apps still on the old one, same device class.
2. Turn the behaviour off. Flip the remote switch for the feature the release changed (CLI 4); signals should recover as apps pick up the new configuration.
3. Stop the spread. Ask the affected teams to pause their staged rollouts; mark the version as "do not adopt" in the library registry.
4. Patch forward. Ship a patch release with the old behaviour as the default; teams take it in their next release. There's no "rollback" of code already on phones.
5. Record it. Add the missing scenario to the conformance kit or the compatibility suite.

Go deeper: CLI playbook

Plain commands an on-call engineer runs, one at a time. Replace the IDs with real ones.

textCopy
# 1. Feed API P99 at the load balancer, last hour
aws cloudwatch get-metric-statistics --namespace AWS/ApplicationELB --metric-name TargetResponseTime --dimensions Name=LoadBalancer,Value=app/paging-alb/50dc6c495c0c9188 --extended-statistics p99 --period 60 --start-time 2026-09-28T09:00:00Z --end-time 2026-09-28T10:00:00Z

# 2. Aurora replica lag on one reader (the service adds it to its settle cutoff)
aws cloudwatch get-metric-statistics --namespace AWS/RDS --metric-name AuroraReplicaLag --dimensions Name=DBInstanceIdentifier,Value=paging-reader-az1a --statistics Maximum --period 60 --start-time 2026-09-28T09:00:00Z --end-time 2026-09-28T10:00:00Z

# 3. Installs with dropped duplicates, by library version, yesterday
aws athena start-query-execution --work-group telemetry --query-string "SELECT lib_version, approx_distinct(install_id) AS installs FROM paging_daily WHERE day = '2026-09-27' AND dup_dropped > 0 GROUP BY lib_version ORDER BY installs DESC"

# 4. Remote switch: deploy the flags version that turns velocity prefetch off
aws appconfig start-deployment --application-id a1b2c3d --environment-id e4f5g6h --configuration-profile-id k7l8m9n --configuration-version 12 --deployment-strategy-id AppConfig.AllAtOnce

# 5. Telemetry stream throttling
aws cloudwatch get-metric-statistics --namespace AWS/Firehose --metric-name ThrottledRecords --dimensions Name=DeliveryStreamName,Value=paging-telemetry --statistics Sum --period 300 --start-time 2026-09-28T09:00:00Z --end-time 2026-09-28T10:00:00Z

# 6. Scale the paging service
aws ecs update-service --cluster paging --service paging-api --desired-count 120

R3.10 Pillar Check

R3.11 Round 3 Rubric and Follow-Ups

What an architect (L7) answer adds over L6

• Separates what the library owns (caching, window, diff, states, prefetch) from what a team owns (a data source), and writes the contract's rules, not just its signature.
• Knows keyset's assumption (sort keys don't move) and uses ranking sessions where it breaks, with an expiry path that doesn't jump.
• Applies edits and deletes through the same database, guarded by versions and tombstones, so ordering of updates doesn't matter.
• Designs accessibility into the library's behaviour.
• Treats defaults as API and as capacity, and designs releases for code that can't be recalled.
• Builds telemetry that counts people, not events, with no content.
• Sizes session state, telemetry volume and quotas, and catches the Firehose throughput limit.

Follow-up questions

1. "The feed backend goes multi-region. What happens to cursors and ranking sessions?" Answer: keyset cursors hold values, not server state, so any region with the same data can serve them; the settle window must then also cover cross-region replication lag for any region that serves newer reads, or newer reads stay in the region that took the write. Ranking sessions are server state: either keep a user's session in their home region and route by it, or treat a failover like expiry, a 410 and a new session appended below. The second is simpler and already tested.

2. "A team wants the list to jump to 'page 40' of search results." Answer: in network mode their data source can use offsets if the search API supports it, and the library's placeholders need a count: the contract's items_before and items_after. We'd support it for search because results are a frozen snapshot per query. We'd refuse it for live feeds, where "page 40" doesn't mean anything stable.

3. "How would you know the settle window is long enough in production?" Answer: it isn't a fixed number we hope is long enough: each task computes it per request from the lag it measured a second ago, and moves head and newer reads to the writer when lag is unknown or above 5 s. What we still verify is the commit side: the server logs, per write, the time from created_at to commit, which statement_timeout (or transaction_timeout) caps at 1 s. A nightly job can also look for posts whose commit came later than the cutoff allowed, and a refresh whose head page spans such a post repairs it on the phone.

---

Loop Closer: Interview Strategy for All Three Rounds

How to Run Each 60-Minute Round

For how to spend a single 45-minute round, see the 45-minute interview blueprint.

The Two Sentences That Matter Most

• Opening a round: "Before I design: what's the sort order, can items be added or removed while someone scrolls, and what devices set the memory and frame budget?"
• When the scope is raised: "Here's what breaks, and I'll fix it in this order: anything that repeats or loses items, then anything that moves the list under the reader, then memory and frames, then bytes and cost."

Well-Architected Review Sheet

Interviewers rarely ask "which pillar is this?". They ask the pillar's question in plain words. Rehearse one sentence per row.

Rubric Across Levels