Data & Persistence

Caching — L1 (Level 1), L2 (Level 2), L3 (Level 3) Architecture

Caching is multi-layered. Always describe all three layers. Each trades speed for capacity and durability.

• 1. Check L1 (memory) — if hit, return immediately
• 2. Miss → check L2 (disk/Room) — if hit, populate L1 and return
• 3. Miss → fetch from network — populate L2 then L1, then return
• 4. On write — update L1 and L2 immediately; sync to server asynchronously

Interview tip: Say: 'I use a three-layer cache — in-memory LruCache for hot data, Room for warm data that survives process death, and the network as source of truth. I invalidate with ETags for REST and TTL for feeds.'

Cache Invalidation Strategies

Knowing when to invalidate cache is as important as knowing how to cache.

Room & Local Persistence

Key concepts for local data storage in Android.

• Room + SQLite (Structured Query Language) — primary structured store; use transactions for atomicity
• DAO (Data Access Object) with Flow — Room DAOs (Data Access Objects) can return Flow<List<T>>; automatically emits on DB (Database) change
• Database transactions — wrap multi-table writes in withTransaction to prevent partial state
• Migrations — always write forward migrations; test with MigrationTestHelper on every version bump
• DataStore — replace SharedPreferences; coroutine-safe, Flow-based, type-safe with Proto DataStore
• Indices — add @Index on columns used in WHERE clauses; critical for query performance on large tables

Paging 3 — Deep Dive

Paging 3 is the correct way to load large datasets. Know the internals, not just the API (Application Programming Interface).

• Cursor pagination preferred over offset — consistent results under concurrent inserts; offset-based pagination can skip or duplicate items when the list changes during scroll
• Error handling — LoadState.Error in header/footer items; retry via lazyPagingItems.retry()
• Prepend vs append — append = load next page; prepend = load newer items at top (e.g. new messages in chat)

Offline-First Architecture

The gold standard for mobile apps that need to work without connectivity.

• Write local DB first, sync to server asynchronously — never block UI on network
• Optimistic UI — show result immediately; rollback on server error
• Outbox pattern — persist pending operations in a queue (Room table); drain with WorkManager
• Conflict resolution — last-write-wins (simple), server-wins (safe), custom merge (chat, docs)
• Eventual consistency — client and server may temporarily diverge; this is acceptable for most mobile apps

Synchronization Strategies

Different sync strategies for different use cases.

Multi-Device Sync

User sends a message on their phone — their tablet must reflect it. This requires a device-aware sync model, not just client-server sync.

• deviceId — each device has a unique ID; server uses it to exclude the sender from push fanout
• Server timestamp — server assigns authoritative timestamp; never trust client clocks for ordering
• lastSyncedTimestamp per device — each device tracks its own sync cursor; delta sync fetches only events after that cursor
• Deduplication on receive — if device receives its own message via push, check clientMessageId against local outbox; discard if already SENT
• Conflict window — two devices editing the same record simultaneously; resolve with last-write-wins (simple), CRDT (collaborative docs), or server-merge

Message Reliability

Critical for chat, payments — any system where duplicate or lost messages are unacceptable.

• clientMessageId = UUID — client generates before send; server deduplicates on it
• Idempotency keys — same key = same result; always safe to retry
• At-least-once + server dedup — safer than at-most-once for message delivery
• Exponential backoff — never retry immediately on failure

Interview tip: Message state machine: PENDING → SENT → DELIVERED → READ (and FAILED from any state on terminal error)

CRDT & Conflict Resolution — G-Set, LWW-Register, OT, RGA

When two devices edit the same data simultaneously, you need a conflict resolution strategy. Last-Write-Wins (LWW) is simple but lossy. CRDTs (Conflict-free Replicated Data Types) are mathematically merge-safe — each type suits different use cases.

• CRDTs guarantee that any two replicas converge to the same state regardless of operation order or network partitions
• Vector clocks vs wall clocks — never use wall clock for causality; use a Lamport timestamp or vector clock
• Yjs (2023) and Automerge (2.0, 2023) are production-ready CRDT libraries used in Notion, Linear, and Figma
• For mobile offline-first: LWW-Register per field covers 90% of use cases; only reach for full CRDT for collaborative editing
• Three-way merge — git-style: find common ancestor, merge both branches' diffs; used by some sync engines (e.g. Electric SQL)

Interview tip: Say: for a collaborative document feature I'd use a CRDT — specifically Yjs or Automerge — because they provide conflict-free merges without a central server arbitrating. For simpler cases like profile edits I'd use LWW-Register with vector clocks rather than wall-clock timestamps.