Mobile System Architecture and Offline-First Design Questions

High-level goal
Validate that creating/editing notes offline, then reconnecting, results in correct sync, robust retry/backoff, predictable conflict resolution, safe app restarts, and clear UX messaging.

Environment & tools

• Devices: iOS and Android (one each), multiple OS versions
• Tools: airplane mode, Charles/Fiddler for network manipulation, adb/idevicesyslog, app build with debug logging

Step-by-step test plan

1. Prepare

• Sign in and ensure baseline notes exist; note server clock and last-sync timestamp.

2. Offline create

• Turn on airplane mode. Create Note A (title, body, attachment). Expected: note saved locally, UI shows “Unsynced” or sync icon; no crashes; local DB entry with temporary client-id and modified timestamp.

3. Offline edit

• Edit Note A and create Note B. Delete Note C (existing). Expected: local changes recorded in operation queue with incremental sequence numbers.

4. Reconnect + happy path

• Disable airplane mode. Observe automatic sync. Verify:
  • Notes appear on server (via backend or another client).
  • Local temporary IDs replaced with server IDs.
  • UI shows success toast and removes “Unsynced” state.
  • Verify timestamps and content match.

5. Retry/backoff handling

• Simulate flaky network: reconnect but throttle or drop requests. Verify exponential backoff occurs (logs), no duplicate ops, retry intervals increase, and eventual success when network stable.

6. Conflict cases

• Setup: On Server/other device, edit Note A while offline on device. Reconnect. Verify conflict resolution policy:
  • If last-write-wins: verify the correct version prevails and user is informed.
  • If merge with user choice: verify conflict UI prompts with clear options (Keep mine / Keep theirs / Merge), and choice applies correctly.

7. App restart during sync

• Start sync, then force-close app or reboot device mid-sync. Reopen app and verify:
  • Sync resumes or restarts safely.
  • No duplicate notes or partial states.
  • Operation queue persists and continues.

8. UX messaging checks

• Ensure messages are actionable and consistent: “Offline — changes saved locally”, “Syncing…”, “Sync failed — Retry”, conflict dialogs show diffs, success toasts non-intrusive.

9. Edge and error cases

• Large attachments offline; ensure upload resumes or fails gracefully.
• Server rejects operation (validation error); verify user sees error and can edit/fix.
• Clock skew: create edits with device time changed; verify server uses server timestamps and promotes consistent ordering.

10. Verification & logs

• Cross-verify server records, client DB, and another signed-in device.
• Capture logs for retries, conflict resolution decisions, ID mappings.

Acceptance criteria

• No data loss or duplication.
• Predictable conflict handling per spec.
• Reliable retry/backoff behavior.
• Clear UX messaging at each state.

Overview
Below are main background sync mechanisms on Android and iOS, their typical constraints, and implications for an offline-first sync design.

Android

• WorkManager (wraps JobScheduler/Fallbacks)
  • Constraints: deferrable, battery-aware, respects Doze; can require network type, charging.
  • Scheduling precision: best-effort, not exact.
  • Effect on offline-first: use WorkManager for periodic reconciliation and retries; design idempotent operations and local queueing so work can run when network/charging conditions permit.
• JobScheduler (API level specific)
  • Constraints: Doze/standby aware, limited frequency, batching.
  • Precision: coarse.
  • Effect: batch updates to save battery, avoid expecting immediate sync.
• Foreground Service
  • Constraints: visible notification, higher power cost.
  • Precision: can run continuously — suitable for realtime/sensitive sync.
  • Effect: use sparingly (e.g., active file uploads) and fall back to WorkManager for background.

iOS

• BGTaskScheduler (BGProcessingRequest / BGAppRefreshTask)
  • Constraints: system decides runtime, may require external power (BGProcessing), limited runtime.
  • Precision: coarse; not guaranteed timing.
  • Effect: schedule background processing for bulk reconciliation; keep tasks resumable and idempotent.
• Background Fetch
  • Constraints: frequency adaptive to usage, short runtime.
  • Precision: unpredictable.
  • Effect: use to opportunistically pull small deltas; do not rely as sole sync.
• Silent Push Notifications (notification-triggered tasks)
  • Constraints: delivery not guaranteed, rate-limited, may be throttled if abused.
  • Precision: near-real-time when delivered.
  • Effect: use to trigger immediate short syncs; always fallback to local-queued work if push absent.

Design implications (cross-platform)

• Make sync idempotent, resumable, and chunked.
• Keep local state authoritative; enqueue operations locally and mark pending.
• Respect network constraints: support offline queue, exponential backoff, and conditional sync on unmetered/charging if heavy.
• Prefer small delta syncs and server endpoints supporting resume/partial sync to fit limited runtime windows.

Approach (brief)

Use a LinkedHashMap with accessOrder = true to maintain LRU ordering and a running total size. Keep O(1) get/put by map operations and update size on insert/remove. Ensure thread-safety with a single ReentrantLock (or synchronize) to avoid race conditions during reads/writes and eviction.

Kotlin implementation

import android.graphics.Bitmap
import java.util.LinkedHashMap
import java.util.concurrent.locks.ReentrantLock
import kotlin.concurrent.withLock

class LruBitmapCache(private val maxBytes: Long) {
    private val lock = ReentrantLock()
    // accessOrder=true -> iteration order is LRU -> MRU
    private val map = object : LinkedHashMap<String, Bitmap>(16, 0.75f, true) {}
    private var currentSize = 0L

    fun get(key: String): Bitmap? = lock.withLock {
        return map[key] // accessOrder ensures this marks it as recently used
    }

    fun put(key: String, bitmap: Bitmap, sizeInBytes: Int) = lock.withLock {
        val prev = map.put(key, bitmap)
        if (prev != null) {
            currentSize -= sizeOf(prev)
        }
        currentSize += sizeInBytes
        evictIfNeeded()
    }

    private fun evictIfNeeded() {
        val iter = map.entries.iterator()
        while (currentSize > maxBytes && iter.hasNext()) {
            val entry = iter.next()
            val removed = entry.value
            currentSize -= sizeOf(removed)
            iter.remove()
            // optionally recycle bitmaps: removed.recycle()
        }
    }

    private fun sizeOf(bitmap: Bitmap): Int {
        // API-safe: bytes per row * height or bitmap.byteCount on newer APIs
        return bitmap.byteCount
    }
}

Key points & trade-offs

• Data structures: LinkedHashMap(accessOrder=true) + hashmap semantics -> O(1) lookup and ordering.
• Concurrency: ReentrantLock ensures atomic get/put/evict. For higher read concurrency, consider ReadWriteLock or lock striping, but must ensure consistent size accounting.
• Eviction: done inside put while holding lock to avoid races.
• Memory: track byte sizes precisely; handle large single items (if item > maxBytes decide to reject or clear cache first).
• Android notes: consider using Bitmap.recycle() if appropriate and watch for bitmap.byteCount availability across API levels.

Situation overview / goal
Quickly identify whether notifications or background syncs introduced the battery regression, quantify impact, and implement low-risk fixes that preserve functionality.

Client-side data to collect

• Per-device samples: OS version, model, app version, foreground/background state, uptime.
• Timeline logs: timestamped events for receipt of push, start/end of background job, CPU wake-locks, network transfers, and notification display.
• Energy metrics: battery drain rate before/after release, wakelock duration (Android PowerManager), iOS energy usage from Instruments.
• Telemetry counts: number of pushes received, silent pushes, background fetch runs, retries, bytes transferred.
• Sampling window: collect anonymized traces for a representative cohort (low/medium/high activity users).

Server-side data to collect

• Push send rate per user, per device token, priority flags (FCM high/normal, APNs priority).
• Payload sizes and patterns (frequency, duplication).
• Sync scheduling decisions, failure/retry rates, and server-side batching/coalescing behavior.
• Correlate server send timestamps with client-received timestamps.

Instrumentation to add

• Lightweight event tracing (timestamped) around: onMessageReceived, startJob, network request begin/end, wakelock acquire/release, notification post/dismiss.
• Counters and histograms: background job duration, bytes, CPU active time, number of pushes per hour.
• Toggleable verbose mode for deeper trace (only enabled for affected cohort).
• Remote-config flags to flip behaviors (priority handling, batching, backoff) for experiments.

Experiments / A-B tests

• A: Reduce push priority from high to normal for N% of users and measure battery + UX metrics (latency to notify).
• B: Server-side coalescing: batch updates into 1 push per X minutes vs immediate pushes.
• C: Client-side debounce: ignore duplicate pushes within Y seconds and test battery/accuracy tradeoff.
• D: Switch silent pushes to scheduled periodic sync via WorkManager (Android) / BGAppRefresh (iOS) for low-critical updates.
  Measure battery drain, notification latency, missed/duplicated notifications, user engagement.

Potential fixes to push

• Server: coalesce and rate-limit pushes per user; reduce payload size; mark non-urgent pushes as normal priority.
• Client: respect Doze/Background Restrictions; move work to JobScheduler/WorkManager (Android) or BackgroundTasks (iOS); avoid holding wakelocks—use JobScheduler for network; batch network calls; exponential backoff for retries.
• Notification UX: aggregate notifications, suppress duplicates, use silent notifications only to trigger light refreshes.
• Monitoring + rollout: enable remote-config to roll back/pivot fast and monitor post-fix metrics.

Outcome & validation
Deploy fixes to small canary, monitor telemetry (battery, background job counts, notification latency), expand rollout if positive.

Situation & goal
Design a push-driven sync trigger so server tells mobile apps “new data” while avoiding battery drain, background limits and thundering-herd.

High-level strategies

• Interest-based routing: subscribe devices to topics/segments (user, conversation, interest tags). Only notify relevant clients.
• Stagger + jitter: add randomized delay (e.g., 0–30s jitter) per-device or per-topic to avoid simultaneous wake-ups.
• Batching: coalesce rapid events on server into one notification window (e.g., 1–5s buffer); send one trigger for multiple changes.
• Exponential backoff / client-side rate-limits: if app recently synced, ignore additional triggers for a cooldown; server tracks last-sync timestamp per-client and respects minimum interval.

Server-side rate limiting & prioritization

• Prioritize urgent vs informational: assign priority flag; only high-priority sends immediate trigger. Low-priority go to batched queue.
• Global and per-user QPS caps to protect APNs/FCM and backend.
• Backpressure: if backend overloaded, convert non-critical pushes to silent flags to be pulled later.

Platform background limits

• iOS: content-available pushes can be throttled by the OS; don't rely on guaranteed delivery or execution time. Use VoIP/pushkit only when appropriate and allowed.
• Android: data messages may be blocked under Doze/Background restrictions—use high-priority sparingly; prefer WorkManager for guaranteed background work after wake.
• Always design for missed pushes: implement periodic background fetch or resume-on-open full sync.

Payload vs wake-only

• Wake-only (minimal): send no data when server simply needs client to fetch latest; best when payloads large, sensitive, or when you want server-side consistency checks.
• Small payload (delta): embed tiny JSON (version id, changed IDs, lightweight delta) when it reduces round-trips and fits platform limits; ensure payload < 4KB for APNs.
• Never include sensitive data in push; treat pushes as hints only.

Client implementation patterns

• On receiving trigger: check lastSyncTime, apply jitter, decide to full/paged/delta sync.
• Ack/heartbeat: client optionally confirms sync success so server can stop retrying.
• Retry/backoff policy: exponential backoff with random jitter on failed syncs.

Metrics & instrumentation

• Track push delivery, wake callbacks, sync latency, battery impact, and failed/queued notifications to tune jitter, batch windows and rate limits.

This design balances responsiveness with battery and platform constraints by combining targeted routing, jittered delivery, server and client rate-limiting, and choosing payload vs wake-only on a per-priority basis.