Netflix Staff Mobile Developer Interview Preparation Guide

Approach overview

• Bump Realm schema version; write migration that (A) renames property, (B) creates new object and migrates fields from old object then optionally deletes or flags old object.
• Test migrations from N previous releases using upgrade and downgrade-like tests (start DB from old bundled file, open with new schema).

Versioning strategy

• Increment schemaVersion by 1 for each breaking change.
• In commit message and release notes: include schemaVersion, change summary, and migration steps.
• Keep backwards-compatible additions as non-breaking until you need removing/renaming.

iOS (Swift) — migration callback pseudocode

let config = Realm.Configuration(schemaVersion: 5, migrationBlock: { migration, oldSchemaVersion in
    if oldSchemaVersion < 5 {
        // rename property: Person.fullName -> Person.displayName
        migration.renameProperty(onType: "Person", from: "fullName", to: "displayName")
        // split object: UserProfile -> User + Settings
        migration.enumerateObjects(ofType: "UserProfile") { oldObj, newObj in
            let user = migration.create("User", value: [:])
            user["id"] = oldObj!["id"]
            user["email"] = oldObj!["email"]
            let settings = migration.create("Settings", value: [:])
            settings["theme"] = oldObj?["preferredTheme"] ?? "default"
            // link if needed
            user["settings"] = settings
        }
    }
})
Realm.Configuration.defaultConfiguration = config

Android (Kotlin) — migration callback pseudocode

val config = RealmConfiguration.Builder()
    .schemaVersion(5)
    .migration { realm, oldVersion, newVersion ->
        if (oldVersion < 5) {
            // rename field
            realm.schema.get("Person")?.renameField("fullName", "displayName")
            // split object
            val userProfileSchema = realm.schema.get("UserProfile")
            userProfileSchema?.transform { obj ->
                val user = realm.createObject("User")
                user.set("id", obj.get("id"))
                user.set("email", obj.get("email"))
                val settings = realm.createObject("Settings")
                settings.set("theme", obj.getString("preferredTheme") ?: "default")
                user.set("settings", settings)
            }
            oldVersion = 5
        }
    }.build()
Realm.setDefaultConfiguration(config)

Testing migration path

• Maintain a set of Realm files exported from released versions (simulate clients). For each:
  • Put file in app sandbox or test fixture.
  • Open with new build; assert no exceptions and data maps correctly (fields renamed, new objects created, links intact).
  • Write unit tests that programmatically create older-schema Realms (use older configuration or manual JSON) and run migration.
  • Add automated CI job that runs migration tests for last 3–5 schema versions.

Edge cases & notes

• Handle nulls/defaults, duplicate ids when creating new objects, and transactional safety.
• If many users, consider background migration or progressive migration strategy to avoid long main-thread work.

Direct answer

A lowest common ancestor (LCA) query in a general binary tree can be answered with a single postorder-style depth-first search (DFS, a traversal that explores each branch fully before backtracking) that returns node references bubbling up: if a subtree's search finds both target nodes on different sides, the current node is the LCA; if only one side finds anything, that result is passed further up. When the tree happens to be a binary search tree (BST), searching both subtrees isn't necessary at all: comparing the two target values against the current node's key, and walking down toward whichever side both targets agree on, is enough.

Structured elaboration

Approach: general binary tree

• Recurse into both children. At any node, if the node itself is one of the two targets, or if the node is None, return it directly (a None or a matched target both act as the "nothing more to find below here, here's what was found" signal).
• After the recursive calls return, if both the left and right calls found something non-None, the current node sits between the two targets, so it is the LCA; return it.
• If only one side found something, that result (the target itself, or an LCA found deeper down) is passed up unchanged, since the current node cannot be the answer.

class TreeNode:
    def __init__(self, val, left=None, right=None):
        self.val = val
        self.left = left
        self.right = right


def lca_general(root, p, q):
    """Lowest common ancestor in a general binary tree. p and q are TreeNode
    references known to exist in the tree."""
    if root is None or root is p or root is q:
        return root
    left = lca_general(root.left, p, q)
    right = lca_general(root.right, p, q)
    if left and right:
        return root
    return left if left else right

Approach: binary search tree

• In a BST, every node's key already encodes where its descendants live relative to it, so two arbitrary nodes don't require searching both subtrees.
• Starting at the root, compare both target values to the current node's key: if both are smaller, the LCA must be in the left subtree, so move left; if both are larger, move right; if they split (one on each side, or either target equals the current key), the current node is the LCA, since that's the first point where the two search paths diverge.
• This turns an O(n) full-tree traversal into an O(h) walk that only ever moves in one direction, without exploring both children at any step.

def lca_bst(root, p_val, q_val):
    """Lowest common ancestor in a binary search tree, using key comparisons
    instead of exploring both subtrees."""
    node = root
    while node is not None:
        if p_val < node.val and q_val < node.val:
            node = node.left
        elif p_val > node.val and q_val > node.val:
            node = node.right
        else:
            return node  # values split here (or one equals node.val): this is the LCA
    return None

Key points

• The general-tree version explores every node in the worst case, since it has no way to prune a subtree without checking it.
• The BST version needs no recursion into both sides at all; it reuses the same "which direction do both targets agree on" comparison as an ordinary BST search, walking a single path from the root.

Worked example

Building this tree:

        6
      /   \
     2     8
    / \   / \
   0   4 7   9
      / \
     3   5

This tree also happens to satisfy the BST ordering property (every left descendant is smaller, every right descendant larger), so both functions can be run on it and compared directly. lca_general(root, node(2), node(8)) and lca_bst(root, 2, 8) both print 6 (the two nodes sit in different subtrees of the root). lca_general(root, node(2), node(4)) and lca_bst(root, 2, 4) both print 2 (node 2 is an ancestor of node 4). lca_general(root, node(3), node(5)) and lca_bst(root, 3, 5) both print 4 (they are siblings under node 4).

Trade-offs & pitfalls

Complexity

General binary tree: Time $O(n)$, visiting every node once in the worst case, since there's no way to prune a subtree that hasn't been checked. Space $O(h)$ for the recursion stack, where $h$ is the tree's height ($O(\log n)$ balanced, $O(n)$ degenerate).
Binary search tree: Time $O(h)$, a single downward walk with no backtracking. Space $O(1)$ with the iterative version shown, or $O(h)$ if written recursively.

Edge cases

• One of the two targets is an ancestor of the other: both approaches correctly return the ancestor itself as the LCA.
• p and q are the same node: returns that node.
• p or q is not actually present in the tree: both implementations shown assume presence and will return a plausible-looking but wrong answer rather than erroring; a production version should verify both nodes exist first, a separate O(n) or O(h) check, if that guarantee doesn't already hold elsewhere.
• A deeply skewed tree: the general-tree recursive version risks hitting the language's recursion limit; converting to an explicit iterative stack avoids that.

Applying the BST shortcut to a tree that is not actually a BST silently gives a wrong answer with no error, since the comparison-based walk assumes an ordering invariant that a general binary tree doesn't provide; always confirm which structure is actually in hand before choosing the approach. A second common mistake in the general-tree version is comparing node values instead of node identity when duplicate values are possible, which can match the wrong node entirely.

Direct answer

Structure a technical explanation as a small number of steps that each answer one question the listener actually has, in the order they would naturally ask it: what is this, why does it matter, what are the pieces, how do they work together, show me one real case, then open it up. That ordering reduces how much a listener has to hold in their head at once, and it gives you a clear place to pause and reset if a question knocks you off track.

Structured elaboration

A six-step scaffold maps to how listeners actually process a new topic: overview, context, components, flow, example, then questions.

• Overview: one sentence stating what this is and why it's worth the next five minutes. Orients attention before any detail arrives.
• Context: the business driver or constraint that made this necessary. Information without a reason attached gets forgotten fast.
• Components: name the pieces and what each one is responsible for. Breaking a system into named chunks is what lets someone reason about three things instead of one overwhelming thing.
• Flow: how the pieces interact, in sequence or as a simple diagram. This is where most confusion actually lives, so it comes only after the listener has the vocabulary from Components to follow it.
• Example: one concrete, real case, ideally with a specific input and outcome. Abstract structure becomes retrievable once it's attached to something real.
• Questions: reserved deliberately for the end, so side-questions don't derail the sequence before the listener has enough context to ask a well-formed one.
  Why this order works cognitively: each step only introduces what the previous step already gave the listener a place to put. Naming the pieces before explaining how they interact means the listener isn't hearing an unfamiliar noun and a new relationship in the same sentence, which is what actually causes people to check out midway through a technical explanation.

Worked example

Explaining an event-driven order pipeline to a stakeholder group:
"This is how we process an order the moment it's placed, instead of checking for new orders every few minutes (overview). We built it because the old approach meant a customer's order confirmation could lag noticeably behind the order itself, which was showing up in support tickets (context). There are three pieces: the order service that records the order, a queue that holds it briefly, and a fulfillment service that picks it up (components)."
Someone interrupts: "Wait, what's a queue?" That's a clarification, not a deep-dive, so it gets a one-sentence answer on the spot: "Just a waiting line for messages, so the order service doesn't have to wait around for fulfillment to be ready." Then a bridge back: "So, picking back up at the queue," and the flow step continues from where it left off, rather than restarting.
If instead the question had been "how do you handle a failed fulfillment attempt," that's a deep-dive: acknowledge it, give a short answer or note it for the questions step at the end ("good one, let's come back to that once you've seen the whole flow"), and resume with a short recap sentence to re-anchor everyone before continuing.

Trade-offs and pitfalls

The scaffold breaks down if context gets skipped: a listener who never hears why something matters will tune out before components even starts, no matter how clean the rest of the structure is. Treating every interruption as worth a full deep-dive derails the sequence and loses the rest of the room; treating every interruption as a distraction to defer makes the audience feel unheard. The judgment call is a quick read of the question itself: is this person missing one word (answer now), or missing the shape of the whole thing (that's a sign to zoom back out to overview, not push forward into more detail).

There's a menu of lightweight ways to de-risk an ambiguous ask, and the named ones (a spike or POC, a scoped ticket built on stated assumptions, deferral, a quick prototype) aren't the whole list; techniques like a fake-door test, a Wizard-of-Oz stand-in, a small pilot, or simply looking at data you already have all belong on the same menu. The skill isn't memorizing the menu, it's matching the technique to what kind of ambiguity you actually have, and then keeping whatever you pick from quietly turning into the real build.

Match the technique to the unknown.

• If you don't know whether the question is even still open: check data you already have first, always, before building anything new. Support tickets, existing analytics, a past retrospective; this costs close to nothing and sometimes the question is already answered.
• If the unknown is demand (will anyone want this): a fake-door test, a button, link, or landing page for something that doesn't exist yet, measuring click-through, tells you demand without building the thing.
• If the unknown is the shape of the interaction, not whether people want it: a Wizard-of-Oz stand-in, a human manually doing what the automation would eventually do, tests the experience without building the automation, which is usually the expensive part.
• If the unknown is technical feasibility, can this even be built the way we're imagining: a timeboxed spike or proof of concept.
• If the ambiguity is small and low-stakes: skip the experiment entirely, write a scoped ticket on a stated assumption, get a quick nod from whoever owns the area, and move.
• If you need real usage signal at modest scale before deciding to go further: a small pilot.
• If the cost of being wrong is low and nobody is actually blocked waiting on you: defer, explicitly, rather than spending effort now.

How you know a lightweight prototype is enough, and don't need something bigger. Three signals: the decision is reversible and low blast radius if you're wrong, the disagreement is about one narrow factual question rather than a whole strategic direction, and a small number of examples or users would plausibly settle it either way. If any of those isn't true, for example the decision is expensive to undo, escalate to a bigger test rather than trusting a five-user prototype.

If it succeeds, what you hand to engineering isn't the throwaway code, it's a one-page brief: the assumption that got validated, the specific approach that worked, the known limitations the prototype deliberately skipped (auth, scale, error states), and a link to the throwaway artifact clearly labeled "not production," so engineering rebuilds the thing properly instead of hardening code that was never meant to survive contact with real load.

Keeping it bounded, in three dimensions.

• Time: a hard calendar boundary with a decision meeting already on the calendar, not "we'll know when we're done."
• Cost: a person-hour ceiling stated up front, for example one engineer for three days, 24 person-hours, and an explicit rule that production-grade requirements (auth, scaling, full error handling) are out of scope for this round.
• Scope: a written "won't do" list next to the "will do" list, and a rule that any request to expand scope becomes a separate, newly-approved ticket rather than silently absorbed into the current one.

Worked example. A PM has an ambiguous ask: would users want a saved-search alert feature. Retrospective check first: support tickets mentioning this over the last quarter are frequent but not conclusive enough to build on their own. Fake-door test: a "Get notified" button on the search results page for 2 weeks to 5% of traffic. Threshold set before launch: above 3% click-through, build it; below 1%, shelve it; between 1 and 3%, run one more cheap check. That check is Wizard-of-Oz: manually send a hand-built digest email to the people who clicked and see if they actually open and engage with a manual version before building the automated one.

A different discipline. An SRE has an ambiguous ask: would customers notice if a non-critical endpoint's data freshness degraded. Instead of building automated degradation logic, they Wizard-of-Oz it, manually holding one internal dashboard's data stale for a day and watching whether anyone notices or complains, before writing a single line of the real feature.

The trap: defaulting to the fanciest technique available, a full pilot or a real prototype, when five minutes checking data you already have would have answered the question. The opposite trap is just as real: using a spike to avoid ever writing an assumption down in a ticket and getting a quick answer, when the ambiguity was small enough that asking didn't need an experiment at all.

Direct answer
Server-side evaluation is generally safer for a rollout because the server can change a flag's value instantly and consistently for every client, while client-side evaluation depends on each device having up-to-date flag configuration, which is exactly what breaks down under intermittent connectivity.

Structured elaboration

• Client-side evaluation: the app itself decides whether a feature is on, usually based on a flag configuration it fetched and cached at some point. Faster to evaluate at request time (no network round-trip needed) and works fully offline, but a device on a stale cache keeps using an OLD flag value until it next successfully syncs, which for an intermittently-connected mobile app could be minutes to hours out of date.
• Server-side evaluation: the server decides on each request. Always reflects the current flag state instantly and consistently, but requires a live connection for every decision that depends on the flag, which is a problem for a mobile app trying to work offline or under a flaky connection.
• Default behavior when a flag can't be fetched: this is the crux of the safety question. The system needs an explicit, deliberately chosen default for "no data available," and that default should almost always be the SAFE, conservative behavior (feature OFF, or the old known-good code path), never "assume the last cached value is still correct" for anything risk-sensitive, since an unreachable device might be running a stale cache for an unknown, possibly long, period.

Worked example
A payment-related feature flag on a mobile app with client-side evaluation: the SDK is configured so that if it can't reach the flag service within a short timeout, it falls back to a hardcoded, safe default (feature OFF) rather than serving whatever was last cached, which might be hours or days stale if the device has been offline. This costs some feature-availability under poor connectivity (some users see the old behavior more often than strictly necessary) in exchange for never risking a stale, potentially-unsafe flag state driving payment logic.

Trade-offs and pitfalls
A hybrid is common in practice: client-side evaluation for speed and offline resilience, paired with a short cache TTL and a conservative, explicit fallback value baked into the SDK for when the cache is stale or fetch fails, rather than a pure binary choice between client-side and server-side. The common mistake is an SDK that silently serves an arbitrarily-old cached value with no TTL or fallback logic at all, which quietly turns "intermittent connectivity" into "unpredictable flag state," exactly the failure mode a well-designed flag system exists to prevent.

Clarify goal (mobile perspective)
Keep profile reads fast (local cache) across iOS/Android/web, ensure updates converge quickly and staleness is bounded, and resolve conflicts predictably.

Versioning

• Server assigns a monotonic profile version (integer) and per-field version ids when fields change.
• Responses include: { profile, version, per_field_versions } or ETag header.
• Clients store local version with cache.

Optimistic updates

• Immediately apply UI-local change and enqueue a mutation with a client-generated op-id and local timestamp.
• Send mutation to API; show pending indicator.
• On ACK with new server version, replace local cache and clear pending op.
• On NACK or conflict, fetch latest and either reapply op (if still applicable) or surface error.

Server-driven invalidations

• Use push (APNs/FCM) carrying profile id + new version or ETag to prompt clients to fetch deltas.
• Fallback: silent background fetch or websocket when available.
• Push ensures low-latency invalidation across devices.

Bounded staleness

• Combine push invalidations + conservative TTL (e.g., 30s) + background refresh on app foreground to guarantee staleness ≤ TTL + push latency.
• Server can send mandatory short TTL for hot profiles.

Conflict reconciliation

• Server performs authoritative merge:
  • Per-field last-writer-wins using server-assigned timestamps or per-field versions.
  • For complex fields (preferences, lists), server uses merge logic (union, last-modified-per-item).
• Client-side: on conflict response include merged result and rationale; client reconciles pending ops by:
  • If pending op still valid, reapply against merged state and resend.
  • If overridden, notify user if necessary (show “update failed” for critical fields).

Trade-offs

• Per-field versions increase metadata but reduce lost updates and user friction.
• Push reduces latency but needs robust token management and battery considerations.

This approach keeps UI snappy via optimistic updates, provides fast cross-client convergence with server-driven invalidations, and bounds staleness with TTL + background sync.

Overview / Goals
Design for scale, team autonomy, testability, fast CI, small releases. Use Clean Architecture + MVVM per feature.

Module boundaries

• app (bootstrap, DI, navigation host)
• core (network, storage, analytics, util)
• features/* (per-domain feature modules: auth, feed, payments) — each owns UI, domain, data
• common-ui (design system, reusable components)
• data-shared (models, mappers, API contracts)
  Modules compile separately; teams own their feature modules.

App architecture

• Clean Architecture layers: Presentation (MVVM + ViewModels), Domain (use-cases), Data (repositories, sources).
• ViewModels expose StateFlow/LiveData, use coroutines for async.
• Repository interfaces in domain, implementations in data module.

Dependency injection

• Use Hilt for app-level graph; each feature provides its own @Module and component bindings.
• Provide interfaces at domain level; bind implementations in feature/data modules.
• Use qualifiers and scopes (Singleton, ViewModelScoped) to control lifetimes.

Navigation

• Use Jetpack Navigation with a single Activity and NavHost.
• Feature modules expose Navigation Graphs via dynamic feature integration or modularized NavGraph provider.
• Deep links and analytics hooks at nav actions.

Offline caching & sync

• Use Room for local cache + Paging 3 for large lists.
• Data source strategy: network-first with cache fallback or cache-first where appropriate.
• Background sync via WorkManager with constraints, incremental sync using ETags/last-updated and conflict resolution via domain rules.

CI/CD

• Per-module builds and static-analysis (Detekt, ktlint), unit & instrumentation tests.
• Incremental builds using Gradle configuration caching & build cache.
• Pipelines: PR checks -> artifact build -> automated test matrix -> staged rollout.
• Fast lanes for bug-fix hotfix releases.

Modular releases / Dynamic features

• Use Android Dynamic Feature Modules for large/rare features (payments, onboarding).
• Keep core flows in base APK; deliver dynamic modules on demand and prefetch based on signals.
• Version APIs/contracts carefully; use feature toggles and backward-compatible APIs.
• Canary/staged rollout via Play Console and remote config to mitigate risk.

Trade-offs

• More modules => faster team autonomy but higher build complexity; mitigate with strict API boundaries and automation.
• Dynamic features add complexity for testing and DI; cure with contracts and integration tests.

This design balances scalability, team ownership, reliability, and user experience for millions of users.

Direct answer. Design the public surface around what the CALLER needs to accomplish, not around your internal implementation details -- keep the surface small, make illegal states hard to represent, and design for evolution (adding capability later without breaking existing callers) from the start.

Worked example: a camera-capture SDK

// A surface shaped around the CALLER's goal, not the implementation
interface CameraCapture {
    fun requestPermission(callback: (Granted) -> Unit)
    fun capturePhoto(options: CaptureOptions = CaptureOptions.default()): CaptureResult
    fun release()
}

Compare this to exposing internal details directly (raw camera device handles, platform-specific capture session objects) -- the caller shouldn't need to understand HOW capture works internally, only WHAT they can ask the SDK to do.

What makes an API hard to misuse

• Make invalid states unrepresentable: rather than a boolean isPermissionGranted the caller must remember to check before calling capturePhoto, the method itself can enforce the check and return a typed result (PermissionDenied | Success(photo)) that FORCES the caller to handle both cases at compile time rather than trusting them to remember.
• Sensible, safe defaults: CaptureOptions.default() lets the common case be a one-line call, while power users can override specific options -- this avoids forcing every caller through a long parameter list for the 90% case.
• Explicit lifecycle: release() makes resource cleanup an obvious, discoverable part of the contract rather than an implicit expectation buried in documentation.

Designing for safe evolution

• Prefer adding a NEW optional parameter with a default (non-breaking) over changing an existing parameter's meaning.
• Return a structured result object rather than a bare value, so adding a new field later (e.g., photo metadata) doesn't require a breaking signature change.
• Version the SDK's public surface explicitly (semantic versioning) so consumers can tell, from the version number alone, whether an upgrade might require code changes.

Trade-offs and pitfalls

• Over-abstracting the surface (hiding EVERY implementation detail behind layers of indirection) can make the SDK harder to debug when something does go wrong, since the caller has no visibility into what's actually happening underneath -- expose enough (logging hooks, diagnostic callbacks) that failures are debuggable without breaking the abstraction.
• A 'safe defaults' design can hide important decisions from callers who actually need to know about them (e.g., silently defaulting to a lower photo resolution) -- make defaults sensible for the COMMON case, but ensure anything with real consequences is visible in documentation even if not required in every call.

Clarify goals & constraints

• Persist full navigation stack (nested Navigators) and widget input state so user returns to the same screen and form values after app is killed.
• Minimize privacy/sensitive data persisted, support schema/versioning, work with Android/iOS lifecycle and cold-start.

High-level approach

1. Capture the navigation stack as a serializable list of route descriptors (route name, route-specific args, nested children).
2. Persist widget state alongside route descriptors using RestorationMixin/RestorableProperty when possible; fallback to manual serialization for custom state.
3. On cold start, read persisted snapshot and reconstruct Navigator stacks and restore widget state.

Serializing navigation stack

• Represent each route as JSON:

{
  "routes": [
    {"name": "/home", "args": {}},
    {"name": "/form", "args": {"formId": "123"}, "child": {"routes":[ ... ]}}
  ],
  "version": 1
}

• Persist to secure local storage (SharedPreferences/EncryptedSharedPreferences, or file/SQLite). Include timestamp and schema version.

Widget state & RestorationMixin

• Use RestorationMixin and RestorableProperty (RestorableTextEditingController, RestorableBool, RestorableInt) to let Flutter capture state automatically across process death.
• For custom objects, implement RestorableProperty<T> to serialize to primitive types.
• Tie RestorableId keys to route descriptors so when rebuilding routes you reattach restoration scopes to restore values.

Reconstruction flow

• On app start: check saved snapshot + restoration data.
• Initialize root RestorationScope; rebuild nested Navigators by pushing routes in order, creating each page with matching restorationId so RestorationMixin binds and repopulates fields.
• For large stacks, consider incremental restore (rebuild only top N screens immediately, lazy-load deeper screens).

Fallback strategies

• If RestorationMixin unsupported (older Flutter/platform) or state corrupted:
  • 1. Conservative fallback: deep-link to the top-most stable screen (e.g., /home) and surface a “Resume session” banner to let user pick saved context.
  • 2. Restore minimal context: route path and small immutable args (IDs), but reload dynamic content from network rather than persisting large blobs.
  • 3. Form replay: cache transient inputs locally (encrypted) and prompt user to restore inputs manually.
• Validate schema/version; perform migrations or drop incompatible snapshot.

Edge cases & best practices

• Avoid persisting sensitive PII or auth tokens; store only IDs and revalidate auth on restore.
• Limit snapshot size; expire old snapshots.
• Test cold-start restoration on both platforms and with nested Navigators, and ensure RestorationMixin keys are stable across builds.
• Monitor and log restore failures to improve UX.

Approach summary
Propose a hybrid protocol combining compact vector clocks (CVC) + dotted-version-vectors (DVV) with optional Hybrid Logical Clocks (HLC) fallback and device grouping to minimize per-device metadata while preserving causality.

Techniques

• Compact vector clocks: assign each device an index in a sparse map; store only non-zero entries per-client (sparse CVC). Good when devices have infrequent updates.
• Dotted-version-vectors: record (dot = (node, counter)) plus a summarized causal stable frontier; enables O(1) per-update metadata and precise causality for individual operations.
• Device grouping: aggregate devices by user-account or region; maintain a group clock instead of every device to reduce vector size.
• Hybrid Logical Clocks: attach a 64-bit HLC timestamp to events to provide monotonic scalar ordering; use with DVV to break ties and reduce ambiguity.

Trade-offs

• Accuracy vs size: DVV + sparse CVC preserves exact causality with smaller average size but requires more complex merge logic. Grouping reduces metadata but may lose per-device causal resolution and cause false concurrency.
• Pruning: periodically compact older entries into a stable frontier; safe if clients can accept eventual loss of fine-grained ancestry.
• Merge complexity: DVV merges require comparing dots and frontiers (O(k) where k = non-zero entries). HLC simplifies comparisons to scalar when causality isn’t ambiguous.
• Mobile constraints: prefer small on-wire metadata, incremental sync, and server-side aggregation. Use DVV for local operations, upload summaries to server; server resolves heavy merges and prunes, pushing compacted fronts to clients.

Recommendation
For mobile apps: implement DVV locally with sparse maps, HLC timestamps for fast ordering, and server-side grouping/pruning. This balances accurate causality, low per-device metadata, and acceptable merge cost while preserving battery and bandwidth.