Skip to content

Caching and pagination architecture

← Back to Architecture

Caching and Pagination Architecture Deep Dive

Overview

Caching and pagination architecture determines perceived performance, data consistency, and backend load behavior. Policy clarity matters more than any single library choice.

Core Concepts

  • cache hierarchy (memory -> disk/db -> network)
  • freshness policy (TTL, version, etag)
  • pagination key strategy (page, cursor, token)
  • invalidation triggers (manual, time, mutation, server signals)

Layer Responsibilities

  • Presentation:
  • display paged state and load/error indicators
  • ViewModel/domain:
  • coordinate refresh/append intents
  • map cache/paging results to UI state
  • Data:
  • enforce cache policy and page merge logic

Data Flow

  1. UI requests initial or next page.
  2. Repository checks cache validity.
  3. If needed, remote fetch runs with paging token.
  4. Data is merged/deduplicated and persisted.
  5. UI observes updated canonical paged state.

Internal Architecture

Key internals to define early:

  • canonical item identity and dedup rules
  • append/prepend retry behavior
  • refresh boundary and stale window policy
  • invalidation after writes that change list ordering

Code Examples

interface FeedPagingRepository {
    fun observeFeed(): Flow<List<FeedItem>>
    suspend fun refresh()
    suspend fun loadNextPage()
}

class FeedPagingPolicy(
    val staleAfterMs: Long,
    val pageSize: Int
)

Common Interview Questions

  • Q: Where should pagination state live? A: Describe data policy explicitly: freshness and invalidation rules, canonical local source, deterministic merge logic, and duplicate prevention with stable keys.
  • Q: Cursor vs offset pagination tradeoffs? A: Describe data policy explicitly: freshness and invalidation rules, canonical local source, deterministic merge logic, and duplicate prevention with stable keys.
  • Q: How do you avoid duplicate items across pages? A: Answer by defining boundaries and ownership first, then place business rules in the correct layer, and finish with testability and change-resilience tradeoffs.
  • Q: What should invalidate cached pages? A: Describe data policy explicitly: freshness and invalidation rules, canonical local source, deterministic merge logic, and duplicate prevention with stable keys.

Production Considerations

  • instrument cache hit rate and page load latency
  • backoff on repeated page fetch failures
  • protect against thundering-herd refresh behavior
  • validate paging under flaky network conditions

Scalability Tradeoffs

  • Pros:
  • better UX latency and lower backend pressure
  • smoother long-list performance
  • Cons:
  • higher complexity in merge/invalidation logic
  • consistency edge cases under concurrent updates

Senior-Level Insights

Staff-level answers should include operational metrics. A good architecture defines how teams measure cache effectiveness, page quality, and sync correctness over time.