Design Mobile Paging & Infinite Scrolling Library Architecture

1. Problem Statement & Scope

System Mission

Design a memory-bounded, flicker-free, bidirectional mobile pagination and prefetching library architecture capable of rendering feeds with millions of items at a silky 120 FPS ($8.33\text{ ms}$ render budget) on low-RAM devices ($< 3\text{ GB}$). The architecture orchestrates a 3-tier caching hierarchy (L1 In-Memory LRU $\leftrightarrow$ L2 SQLite WAL Disk $\leftrightarrow$ L3 Cloud API Network), opaque cursor-based keyset pagination, asynchronous Myers list diffing, dynamic fling-velocity prefetch heuristics, and offscreen page eviction.

Synthesizing vector architecture diagram...

Functional Requirements

1. Opaque Keyset Cursor Pagination: Seek sequential pages using opaque base64 cursor tokens containing composite sort keys (timestamp_epoch_ms, item_id), completely eliminating skipped or duplicated records during real-time timeline mutations.

2. Bidirectional Scrolling Support: Seamlessly support bidirectional pagination:

   • Append: Infinite scrolling downward to fetch older historical items.
   • Prepend: Infinite scrolling upward to fetch newer unread items.
   • Refresh: Pull-to-refresh to fetch head snapshots without clearing existing view state.

3. 3-Tier Caching Architecture:

   $\text{L1: In-Memory LRU Cache} \longleftrightarrow \text{L2: Local SQLite [WAL](/components/07-write-ahead-log-and-lsm-trees) Cache} \longleftrightarrow \text{L3: Cloud API Network}$

4. Dynamic Prefetch Distance Heuristics: Dynamically compute prefetch windows based on flinging scroll velocity: prefetch 3 pages ahead during rapid fling ($> 1,500\text{ px/s}$), 1 page during steady reading, and pause prefetching during stationary pauses.

5. Strict Memory Bounding & Viewport Eviction: Bound loaded items in memory (max_size = 200 items); automatically drop distant offscreen pages from RAM while preserving scroll position via placeholder sizing, maintaining heap usage under $30\text{ MB}$ on devices with $< 3\text{ GB}$ total RAM.

Non-Functional Requirements (SLAs/SLOs)

• UI Smoothness & Frame Budget: Strict 120 FPS ($8.33\text{ ms}$ per frame); zero main-thread layout thrashing, JSON decoding, or diff calculations.
• Client Heap Footprint: Total memory allocated to paging bounded to $< 30\text{ MB}$ regardless of whether the user scrolls through 50 or 50,000 items.
• Backend Keyset Seek Latency: $O(\log N)$ B-Tree index seek latency $< 5\text{ ms}$ ($P99$) in Amazon Aurora PostgreSQL at 20,000 QPS.
• Network Bandwidth Efficiency: Compressed page payloads $\le 25\text{ KB}$ per 20-item page; intermediate in-flight requests cancelled during high-speed flings.
• CAP / PACELC Classification: Local database operates as an AP node prioritizing read Availability and low Latency (PA/EL). Backend Aurora PostgreSQL enforces strong consistency for keyset orderings.

Out-of-Scope

• Virtual list rendering for web HTML DOM tree optimizations (e.g., react-window DOM virtualization).
• Server-side full-text lexical ranking and BM25 relevance scoring.

---

2. Capacity & Scale Estimation

Device, Memory & Traffic Math

• Active Mobile Traders / Readers: 50 Million Daily Active Users (DAU).
• Daily Scrolling Volume: Each active user requests an average of 12 pages per day ($20\text{ items/page} \implies 240\text{ items/day}$). $\text{Daily Paging Page Requests} = 50 \times 10^6 \times 12 = \mathbf{600\text{ Million Page Requests/Day}}$
• Average & Peak Paging QPS: $\text{Avg Paging QPS} = \frac{600 \times 10^6}{86,400\text{ s}} \approx 6,944\text{ QPS}$ $\text{Peak Paging QPS} = 6,944 \times 3.0 \approx \mathbf{20,833\text{ QPS (Provision for 21,000 QPS)}}$
• Network Bandwidth Throughput: Average compressed page response (20 items with author metadata, thumbnails) $= 25\text{ KB}$. $\text{Peak Egress Bandwidth} = 21,000\text{ req/s} \times 25\text{ KB} = 525\text{ MB/sec} = \mathbf{4.20\text{ Gbps}}$

3-Tier Mobile Memory Footprint Sizing

• L1 In-Memory Cache (LRU Viewport Window):
  • Max loaded data models: $200\text{ items} \times 1\text{ KB} = \mathbf{200\text{ KB Heap Data}}$.
  • Decoded Image Bitmap LRU Cache: Capped at 20 visible/cached screen items $\times 1.2\text{ MB} = \mathbf{24\text{ MB Bitmap RAM}}$.
  • Viewholder / Diff state metadata: $\approx \mathbf{1.5\text{ MB RAM}}$.
  • Total Paging RAM Budget: $\mathbf{\approx 25.7\text{ MB}}$ (Safely below the $35\text{ MB}$ threshold for low-RAM devices with $< 3\text{ GB}$ system RAM).
• L2 Local SQLite WAL Disk Cache:
  • Max cached historical records: $2,000\text{ items} \times 2\text{ KB} = \mathbf{4.0\text{ MB SQLite file}}$.
  • WAL journal size: Capped at $4.0\text{ MB}$.
• L3 Cloud Backend Storage (3-Year Horizon):
  • 500 Million total feed/catalog items.
  • Record size in PostgreSQL $= 2\text{ KB}$. $\text{Raw Catalog Storage} = 500 \times 10^6 \times 2\text{ KB} = \mathbf{1.0\text{ TB}}$
  • Amazon Aurora 6-way Multi-AZ storage (physical; Aurora bills the logical 1.0 TB): $1.0\text{ TB} \times 6 = \mathbf{6.0\text{ TB}}$.
  • Composite B-Tree index (created_at DESC, item_id DESC): $500 \times 10^6 \times 64\text{ Bytes} \approx \mathbf{32\text{ GB Index RAM}}$.

Fleet Sizing & Compute Infrastructure

• Amazon Aurora PostgreSQL Cluster: Provision db.r6g.8xlarge (32 vCPU, 256 GB RAM) primary instance. The entire 32 GB B-Tree index resides resident in the PostgreSQL buffer pool (shared_buffers), ensuring all cursor queries execute as in-memory $O(\log N)$ B-tree descents ($< 1\text{ ms}$, ~30 page touches for 500M rows).
• Stateless Paging Service (ECS Fargate): Peak 21,000 QPS. Each container task handles 350 req/sec $\implies \mathbf{60\text{ tasks (20 per AZ across 3 AZs)}}$.

---

3. AWS-First High-Level Architecture

Synthesizing vector architecture diagram...

Follow a feed request. The newest page (/feed/head) is cached at CloudFront for 10 s, so millions of app opens hit the edge rather than the backend. Older pages carry a cursor and go through API Gateway to the paging service in the "Stateless Paging Service Tier" panel, which serves hot timelines from Redis and otherwise runs a keyset query (WHERE id < cursor ORDER BY id LIMIT 20) on Aurora replicas, which stays fast at any depth, unlike OFFSET. On the phone, in the "Mobile 3-Tier Caching Engine Deep Dive" panel, the list view shows items from an in-memory window of up to 200 items; the page fetcher fills that window from local SQLite and SQLite from the network, while a background diff (Myers) applies only the changed rows to the list. Each tier absorbs most requests for the tier below it, so scrolling rarely waits on the network.

Data Flow Walkthrough

1. Viewport Render (L1 Cache Hit): As the user scrolls, the UI list view requests items by index. If the item exists in the L1 in-memory window, it binds to the viewholder instantly ($< 0.1\text{ ms}$) with zero disk or network I/O.
2. Boundary Prefetch Trigger: As the user scrolls within the prefetch distance threshold ($P$ items from the edge), the RemoteMediator calculates current scroll velocity $v = \Delta y / \Delta t$.
3. Local Database Check (L2 Cache Hit): RemoteMediator queries local SQLite. If the next page is already cached, it loads into memory, emits a new snapshot, and Myers diffing animates the insertion at 120 FPS.
4. Cloud Network Fetch (L3 Cache Miss): If local SQLite has reached the end of cached data, RemoteMediator dispatches an asynchronous HTTP/2 keyset request to Amazon CloudFront, routed via API Gateway to the ECS Paging Service.
5. Keyset B-Tree Seek & Generation Guard: Aurora PostgreSQL executes an $O(\log N)$ composite index seek: WHERE (created_at, item_id) < (:cursor_ts, :cursor_id) ORDER BY created_at DESC, item_id DESC LIMIT 20. The 20 items write directly to local SQLite guarded by the active generation token (generation_id), triggering reactive Myers diffing without flickering or layout jitter.

End-to-End Request Tracing Walkthrough

---

4. API Interface Design & Wire Protocols

1. Keyset Cursor Pagination Endpoint (GET /v1/feed/items)

httpCopy
GET /v1/feed/items?limit=20&cursor=eyJjcmVhdGVkX2F0IjoxNzczNjQ4MDAwMDAwLCJpdGVtX2lkIjoiaXRlbV84OGE5MWM3NCIsInNpZ25hdHVyZSI6IjBhZjkyYy4uLiJ9 HTTP/1.1
Host: api.feed.production.aws.internal
Authorization: Bearer <jwt_access_token>
Accept: application/json
Accept-Encoding: gzip, br
X-Client-Velocity-PxSec: 850

Opaque Cursor Format (Base64 Encoded JSON with HMAC-SHA256 Integrity Tag)

jsonCopy
{
  "created_at": 1773648000000123,
  "item_id": "item_88a91c74",
  "signature": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
}

Response: 200 OK

jsonCopy
{
  "items": [
    {
      "id": "item_88a91c75",
      "title": "Scaling Mobile Paging to 120 FPS",
      "author_id": "usr_998124",
      "author_name": "Staff Mobile Architect",
      "thumbnail_url": "https://cdn.feed.com/thumb/88a91c75.webp",
      "created_at_epoch_us": 1773647998200456
    }
  ],
  "page_info": {
    "page_size": 20,
    "has_next_page": true,
    "has_previous_page": true,
    "next_cursor": "eyJjcmVhdGVkX2F0IjoxNzczNjQ3OTYwMDAwLCJpdGVtX2lkIjoiaXRlbV85OTgxMjRhOSIsInNpZ25hdHVyZSI6IjljYTIxYi4uLiJ9",
    "prev_cursor": "eyJjcmVhdGVkX2F0IjoxNzczNjQ4MDIwMDAwLCJpdGVtX2lkIjoiaXRlbV83N2EyMWJjMSIsInNpZ25hdHVyZSI6IjFhZjgyYi4uLiJ9"
  }
}

2. Status Codes & Error Contracts

---

5. Data Models & Storage Architecture

Local SQLite Schema with WAL Mode (mobile_paging_store.db)

sqlCopy
-- Feed Items Table (L2 Disk Cache with Generation Fencing)
CREATE TABLE local_feed_items (
    item_id TEXT PRIMARY KEY NOT NULL,
    title TEXT NOT NULL,
    author_id TEXT NOT NULL,
    author_name TEXT NOT NULL,
    thumbnail_url TEXT,
    created_at_epoch_us INTEGER NOT NULL,
    generation_id INTEGER NOT NULL DEFAULT 1,     -- Fences writes from superseded refresh cycles
    cached_at INTEGER NOT NULL
);
-- Composite Index enabling instant local keyset seeks
CREATE INDEX idx_local_keyset ON local_feed_items(generation_id, created_at_epoch_us DESC, item_id DESC);

-- Page Keys Table (Bidirectional Cursor Tracking with Generation Fencing)
CREATE TABLE local_page_keys (
    item_id TEXT PRIMARY KEY NOT NULL,
    prev_cursor TEXT,
    next_cursor TEXT,
    generation_id INTEGER NOT NULL DEFAULT 1,     -- Prevents stale append/prepend overwrites
    updated_at INTEGER NOT NULL,
    FOREIGN KEY (item_id) REFERENCES local_feed_items(item_id) ON DELETE CASCADE
);
CREATE INDEX idx_page_keys ON local_page_keys(generation_id, item_id);

-- CursorWindow Memory Hygiene & Scoped Statement Finalization:
-- 1. Explicit projection of visible columns only (never SELECT * containing large content blobs).
-- 2. Deterministic try-with-resources / Kotlin use { cursor -> ... } statement scoping.
-- 3. Eliminates native file descriptor leaks and 2MB CursorWindowAllocationException crashes.

Backend PostgreSQL Keyset Schema & Composite B-Tree Index (production_feed_db)

sqlCopy
CREATE TABLE feed_items (
    item_id VARCHAR(64) PRIMARY KEY,
    title VARCHAR(255) NOT NULL,
    content TEXT NOT NULL,
    author_id VARCHAR(64) NOT NULL,
    created_at TIMESTAMP WITH TIME ZONE NOT NULL,
    is_deleted BOOLEAN NOT NULL DEFAULT FALSE
);

-- Crucial: Composite B-Tree index matches exact ORDER BY and WHERE tuple syntax
CREATE INDEX idx_feed_keyset_pagination ON feed_items (created_at DESC, item_id DESC)
  WHERE is_deleted = FALSE;   -- partial index: the AND is_deleted = FALSE predicate must be covered or the seek degrades to a filter scan

-- O(1) Keyset Query Seeking Page 10,000 in < 1.5ms:
SELECT item_id, title, content, author_id, created_at
FROM feed_items
WHERE (created_at, item_id) < ('2026-09-16 12:00:00+00', 'item_88a91c74')
  AND is_deleted = FALSE
ORDER BY created_at DESC, item_id DESC
LIMIT 20;

---