Meta Senior Mobile Developer Interview Preparation Guide

Overview / Goals
Design a client-side sync engine that keeps a local DB (SQLite/Room/CoreData) eventually consistent with server, tolerates offline, conserves battery, retries with backoff, and handles conflicts at scale.

High-level architecture

• Local DB + Sync Engine + Network Layer + Conflict Resolver + Persistent Operation Queue.
• Server exposes incremental change feed (shadow copies / per-record revision vector + timestamp) and batch APIs.

Thread model

• Main/UI: reads from local DB, applies optimistic local writes.
• Background worker thread(s): single-threaded executor for sync jobs to avoid DB contention; small thread-pool for parallel upload batches when safe.
• Use transactions/DB WAL for concurrency.

Scheduling

• iOS: BGTaskScheduler for periodic background processing + push-based silent notifications (VoIP/Remote notification with content-available) to trigger immediate sync. Limit work to short tasks; chain tasks for longer syncs. Respect background fetch budget.
• Android: WorkManager with constraints (unmetered/wifi, battery not low). Use unique periodic and expedited OneTimeWorkRequests for foreground triggers. Fallback to JobScheduler on older devices.

Retry & backoff

• Exponential backoff with jitter per-batch. Persist retry metadata in operation queue. Use HTTP 429/503 headers when present to adapt backoff. Cap retries and surface error to user if persistent.

Conflict resolution

• Hybrid strategy:
  • Use server-assigned revision vectors (CRDTs or OT for complex merges).
  • Default: last-writer-wins using logical clock (lamport timestamp) for simple fields.
  • For business-critical fields, field-level merge rules and server-side authoritative resolution with merge metadata; surface manual conflict UI when automatic merge uncertain.
  • Keep audit/version history to allow rollbacks.

Data-flow for sync

1. Local change -> write local DB, enqueue operation with change-set and local revision; mark UI updated.
2. Background sync picks upload batch (chunked, compressed), sends to server with client revisions.
3. Server returns accepted updates and conflict notices; client applies server diffs in a transaction.
4. Client requests change-feed since last-synced token and applies remote deltas.
5. Update local revision token, ack operations, remove from queue.

Scalability & efficiency

• Batch operations, delta sync (only changed fields), compression, pagination.
• Use push notifications to minimize polling; use network constraints to prefer Wi‑Fi for heavy transfers.
• Metrics and telemetry for sync success, latency, conflict rates.

Edge cases

• Clock drift: use server logical clocks not device time.
• Partial failures: idempotent ops, resume with operation IDs.
• Schema migrations: versioned migrations in DB and through API compatibility headers.

This design balances battery/network efficiency, robust offline support, scalable throughput, and clear conflict handling appropriate for mobile platforms.

Approach — key points

• Represent UI state with a sealed UIState (Loading/Success/Error).
• Expose immutable StateFlow via asStateFlow().
• Use viewModelScope.launch to fetch and ensure cancellation on ViewModel clear.
• Catch exceptions and emit Error; provide a retry function.

Kotlin implementation

// Kotlin
sealed class ItemsUiState {
    object Loading : ItemsUiState()
    data class Success(val items: List<Item>) : ItemsUiState()
    data class Error(val message: String) : ItemsUiState()
}

class ItemsViewModel(private val repository: Repository) : ViewModel() {
    private val _uiState = MutableStateFlow<ItemsUiState>(ItemsUiState.Loading)
    val uiState: StateFlow<ItemsUiState> = _uiState.asStateFlow()

    init { fetchItems() }

    fun fetchItems() {
        _uiState.value = ItemsUiState.Loading
        viewModelScope.launch {
            try {
                val items = repository.getItems() // suspend
                _uiState.value = ItemsUiState.Success(items)
            } catch (e: Exception) {
                _uiState.value = ItemsUiState.Error(e.message ?: "Unknown error")
            }
        }
    }

    fun retry() = fetchItems()
}

Explanation

• MutableStateFlow holds current state; asStateFlow prevents external mutation.
• viewModelScope ensures coroutines cancel when ViewModel is cleared.
• Init loads immediately; retry exposes explicit re-fetch.

Important tests

• Success: repository returns list -> uiState transitions Loading -> Success(items).
• Error handling: repository throws -> Loading -> Error(with message).
• Cancellation: simulate long-running repository and verify coroutine cancels when ViewModel cleared.
• Retry behavior: initial failure then success on retry -> states reflect both attempts.
• Concurrency: multiple rapid fetch/retry calls produce deterministic final state (last call wins).
• Empty list: repository returns empty list -> Success(emptyList) and UI handles it.

Direct answer

A PII-safe logging helper redacts common sensitive patterns (emails, Social Security numbers, credit card numbers) from a message before it is ever written to a log, using compiled regular expressions applied consistently across every log call, while also enforcing structured fields (a correlation ID, a job or request identifier), log-level discipline, and an extensibility point for adding new redaction patterns as new sensitive-data types are identified.

Structured elaboration

Redaction via compiled regex patterns. A small set of well-tested regular expressions, compiled once and reused (not recompiled on every log call, which would be wasteful), match common PII shapes: an email address pattern, a Social Security number pattern (\d{3}-\d{2}-\d{4}), and a credit-card-like sequence of 13 to 16 digits (allowing spaces or dashes as separators, since real card numbers are often written with them). Each match is replaced with a fixed [REDACTED] marker before the message is passed to the underlying logging framework.

Performance considerations. Compiling patterns once at startup (not per-call) and running them against every log message adds a small, roughly-constant regex-matching cost per log call; for a very high-throughput logging path this is measurable but usually acceptable, since the alternative (an actual PII leak into a log aggregation system with far broader read access than the original data source) is a materially worse outcome, and the specific cost can be validated by simply measuring log throughput with and without the redaction step in a realistic load test.

Configuration to extend redaction patterns. New PII patterns identified over time (an internal account-number format specific to the business, for instance) should be addable without modifying the core logging class, via a constructor parameter or configuration file accepting additional patterns, so the redaction logic can grow as new sensitive-data types are identified in practice, not require a code change and redeploy of the core logging utility itself for every new pattern.

Testing and validating at scale. Beyond unit tests confirming each pattern redacts correctly and that non-sensitive messages pass through unchanged, validating "at scale" means running the redaction logic against a genuinely large, realistic sample of actual (or realistically-synthetic) log messages and manually or statistically auditing a sample of the OUTPUT for anything that looks like it should have been redacted but wasn't, since regex patterns can have false negatives on real-world data that a small, hand-written unit test suite won't surface (an international phone number format, a differently-formatted SSN with no dashes).

Structured fields, log levels, and INFO versus DEBUG. Beyond redaction, the logging helper should ensure every log entry carries a correlation ID (tying related log lines from the same request or job together) and a job/run identifier where relevant (for a batch context specifically). INFO-level logging should capture what a normal operator needs to see to understand system behavior (a job started, a job completed, a summary count); DEBUG-level logging can include more granular detail useful only during active troubleshooting, but should still be redacted with exactly the same discipline as INFO, since a DEBUG log accidentally left enabled in production is a very common real-world path by which sensitive data actually ends up in logs.

Differences for a batch job versus a real-time service. A nightly batch scoring job's logging strategy centers on a per-run summary (start time, record count processed, error count, completion status) tagged with a job_id and run_id, since a human reviewing a batch job's logs the next morning wants an overview, not necessarily a line per record. A real-time service's logging centers on a per-REQUEST correlation ID and typically much higher log volume, and needs sampling strategies for very high-traffic endpoints (logging a representative fraction of successful requests at INFO, while still logging every failure) to keep log volume and cost manageable without losing visibility into failures specifically.

Worked example

public class PiiSafeLogger {
    private static final Pattern EMAIL = Pattern.compile("[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,}");
    private static final Pattern SSN = Pattern.compile("\\b\\d{3}-\\d{2}-\\d{4}\\b");
    private static final Pattern CREDIT_CARD = Pattern.compile("\\b(?:\\d[ -]*?){13,16}\\b");
    private final List<Pattern> patterns = new ArrayList<>(List.of(EMAIL, SSN, CREDIT_CARD));

    public PiiSafeLogger(List<Pattern> extraPatterns) { patterns.addAll(extraPatterns); }

    public String redact(String message) {
        if (message == null) return null;
        String result = message;
        for (Pattern p : patterns) result = p.matcher(result).replaceAll("[REDACTED]");
        return result;
    }
}

Verification note: a Java Development Kit was not available in this execution sandbox, so the exact class above was not compiled directly; the identical regular-expression patterns and replacement logic were instead executed against an equivalent Python translation (Python's re module uses the same pattern syntax for these specific expressions) and confirmed: an email address embedded in a sentence is fully redacted; a dashed Social Security number is fully redacted; a spaced 16-digit credit-card-like number is fully redacted; a message containing no PII passes through completely unchanged; and a null input returns null rather than throwing. This confirms the REGEX LOGIC is correct; it does not confirm Java-specific behavior (for example, java.util.regex.Pattern's exact semantics versus Python's re), which is a disclosed limitation of this verification, not a claim of full Java execution.

Trade-offs and pitfalls

Regex-based redaction is a strong first line of defense but is not exhaustive: a credit card number with unusual formatting, a non-US identification number format, or a PII field that doesn't match any recognizable pattern at all (a person's name in a free-text field, which has no distinguishing shape a regex can reliably catch) can pass through unredacted; this is exactly why validating "at scale" against a realistic log sample, not just a handful of unit tests, matters, and why some organizations pair regex-based redaction with an explicit ALLOWLIST discipline (only log fields you've deliberately reviewed) for the highest-sensitivity data flows, rather than relying on a denylist-style redaction pattern to catch everything. The most common real-world failure mode is a DEBUG-level log statement, written during development and forgotten, that logs an entire request or record object directly (bypassing the redaction helper entirely, since it wasn't routed through it) rather than going through this centralized logging path, which is why enforcing that ALL logging goes through a single, redacting logger (not calling a raw print or an unwrapped logging framework call directly) is as important as the redaction logic itself.

Two buckets to sort evidence into

When latency creeps up with no deploy and no traffic event, the cause is either something INSIDE your application's own code path, or something in the environment UNDERNEATH it that changed independently.

Application-code side: what to rule in or out

• An algorithmic path that only gets slow as data volume grows (an O(n) or worse operation over a table, cache, or list that's been quietly growing), with no code change needed to trigger it.
• A slow-growing in-memory structure (an unbounded cache or buffer) creating extra GC (garbage collection) pressure over time.
• A dependency doing progressively more work, e.g. a feature flag (a runtime on/off toggle for a code path, often ramped up gradually) ramping up so more branches execute now than a month ago.
• Connection pool exhaustion as organic call volume grows even without a distinct "traffic event."
• A scheduled or background job whose input data set has simply grown larger.

System side: what to rule in or out

• A noisy neighbor: another workload on shared hardware or a shared cluster now consuming more CPU or I/O.
• A downstream dependency or database that has itself slowed down (index bloat, table growth changing a query plan, a disk filling up and changing I/O characteristics).
• Network path changes (an added hop, slower DNS resolution).
• Working-set growth exceeding available memory, causing more page-cache eviction than before.
• The process getting rescheduled across NUMA (Non-Uniform Memory Access, where memory access latency depends on which CPU socket needs it) boundaries on a multi-socket host.

Evidence that moves you from one side to the other

• Compare profiled CPU time spent INSIDE your own process against end-to-end wall-clock latency. If profiled CPU time hasn't moved but total latency has, the extra time is being spent somewhere your process-level profiler can't see, that points to the system side (network, downstream, disk).
• Check whether the slow-down correlates with a metric that has organically grown over the same period with no deploy involved, e.g. row count in a hot table, cache size, or queue depth. A tight correlation there, with no infra change, points back to the application/data side.
• Check vmstat's steal-time column (st), a nonzero value means a hypervisor took CPU away from your instance for another tenant, a direct system-side signal.
• Check whether a downstream dependency's OWN latency metrics (their p50/p99, not yours) moved in the same window. If theirs moved, the root cause lives downstream, not in your code.

Overview of headers

• Cache-Control: directives like max-age, public/private, no-cache, no-store, must-revalidate. Mobile: use max-age for safe-to-cache responses; private for user-specific content.
• ETag: opaque validator (usually a hash). Server returns ETag; client later sends If-None-Match to check freshness.
• Last-Modified: timestamp validator; client sends If-Modified-Since.
• Vary: tells caches which request headers affect response (e.g., Vary: Accept-Encoding, User-Agent).
• Conditional requests: If-None-Match / If-Modified-Since let server return 304 Not Modified to avoid full payload.

How mobile apps should use them

• Persist responses to disk (HTTP cache or custom) and honor Cache-Control/Expires to avoid network/wake-ups.
• Implement conditional GET: when cache is stale, send If-None-Match; accept 304 and update timestamps without downloading body.
• Prefer ETag when content can change unpredictably; Last-Modified is lightweight when timestamps are reliable.
• Respect Vary to avoid serving wrong cached variant (e.g., different locales, encodings).
• Use short max-age for dynamic UI data, longer for assets; background sync to refresh quietly.

Battery & bandwidth tips

• Batch conditional requests, avoid frequent polling; use exponential backoff.
• Use network-type checks (Wi‑Fi vs cellular) and only refresh large resources on Wi‑Fi unless user opts in.
• Leverage platform HTTP caches (NSURLSession/OkHttp) which handle validators and 304s efficiently.

Common pitfalls

• Ignoring Vary → cache wrong variant.
• Using no-cache/no-store unnecessarily prevents ETag benefits.
• Relying solely on Last-Modified when server clocks are inconsistent.
• Not persisting cache across app restarts.
• Mistakenly caching sensitive auth-protected responses as public.

Implement validators + sensible Cache-Control, respect Vary, and coordinate refresh strategy for best battery/bandwidth savings.

Direct answer

The partnerships that pay off under deadline pressure are almost never built in the moment you need them. They come from investing time in a working relationship with a team before there's a specific ask attached, understanding their priorities and vocabulary well enough that when you do need something urgent, they already trust your judgment and don't need to re-derive context from scratch.

Structured elaboration

1. Choose deliberately where to invest. You can't build deep relationships with every team you might someday depend on. Invest ahead of need in the teams whose dependencies are likely to become recurring or critical-path (on the chain of dependent work that directly determines a deadline), based on how your roadmap or their roadmap is shaping up.
2. Invest with no immediate ask attached. Show up to their planning or triage occasionally, offer help on something low-stakes, or spend time understanding how they prioritize their own queue. The absence of a request is what makes it relationship-building rather than a transaction.
3. Learn their vocabulary and criteria, not just their org chart. Knowing how a team actually decides what's urgent (their SLA, or service level agreement, tiers, meaning their committed response and turnaround times, and their escalation triggers) is what lets you frame a future ask in terms they'll immediately recognize as legitimate.
4. Share your own context too. A partnership that pays off later is two-directional: they should understand your team's constraints and cadence well enough that an urgent ask from you doesn't sound out of character.
5. When the moment comes, lean on the relationship, not authority. The payoff isn't that they're obligated to help, it's that they already trust your scoping and don't need to independently verify the ask is real before acting on it.

Worked example

As a backend engineer, I noticed my team periodically needed fast turnaround from the support team but had no real relationship with them beyond ticket queues. Over a few months, with no active request pending, I started sitting in on their triage session once a month, just listening and asking questions about how they decided what jumped the queue. In one of those sessions I noticed a complaint that kept resurfacing: a specific error support couldn't explain, so they were closing the tickets as "can't reproduce." I flagged it to the engineer on our side who owned that area, and made sure support knew we were looking into it even though nothing was urgent yet.

Months later, that same underlying issue caused a customer escalation with a tight deadline attached. I reached out directly to the support lead I'd built rapport with, framed the ask using the same triage language they used internally, and was specific about why it was time-sensitive. Because they already trusted that I didn't cry wolf and that my scoping was accurate, they fast-tracked the escalation ahead of their standard queue without needing the usual back-and-forth to validate it was real.

(Swap the domains freely: the same pattern works with a platform team, a design team, or a data team in place of support, as long as the investment happens before there's an active ask.)

Trade-offs & pitfalls

• Pitfall: relationship-building that's transparently transactional (showing up only when you're about to need something) reads as insincere and doesn't produce the trust you're after.
• Pitfall: investing broadly and shallowly across every team instead of selectively where dependencies are likely to matter. That spreads your own team's time thin for little return.
• Pitfall: treating the payoff as owed. A relationship earns goodwill; it doesn't guarantee compliance, and presuming it does damages the very trust you built.
• Senior differentiator: recognizing which dependencies are likely to become critical-path before they do, and investing ahead of the need rather than starting the relationship the day you first need a favor.

High-level approach
Store a small versioned envelope in local storage that contains a header (version, schema id, timestamp), an integrity tag, and an encrypted payload. Use authenticated encryption, per-install keys backed by platform secure storage, and explicit schema migration logic with safe fallbacks.

Format

• Header: { magic: "UISTATE", version: int, schema: string, created: iso8601 }
• Payload: encrypted bytes (serialized protobuf/CBOR)
• MAC/AEAD tag appended

Encryption & key management

• Use AES-256-GCM or ChaCha20-Poly1305 (AEAD) for confidentiality + integrity.
• Derive a data-encryption-key (DEK) per-install from a randomly generated master key (MK).
• Store MK in Keychain (iOS) / Android Keystore with hardware-backed protection; mark non-backupable if secret must not survive device transfer.
• Use envelope encryption for rotation: encrypt DEK with MK; on rotate generate new DEK, re-encrypt payload offline or lazily on next save.
• Support optional user-bound key (Biometric/Passcode) via Keychain/Keystore access control for higher protection.

Schema & versioning

• Use compact binary schema (protobuf/CBOR) with explicit fields and schema version.
• Each envelope header includes schema id + version.
• Implement migration functions: migrate_v1_to_v2(obj) ... keep a chain or upcast path on restore.
• Prefer additive changes; avoid renaming fields without aliases.

Restore & error handling

• On restore:
  1. Verify header magic and AEAD authenticity tag; if verification fails -> treat as corrupt.
  2. Decrypt using current DEK (unseal DEK from MK).
  3. Parse by schema version. If older version, run migrations in order. If newer/unknown version:
     • If forward-compatible: ignore unknown fields and proceed.
     • Else: fallback to safest behavior (discard payload, prompt user to re-enter or offer partial read of known fields).
• Corrupt/missing cases:
  • Log telemetry (no PII) + increment corruption metric.
  • Offer UX: "Restore failed; continue with default state" or "Retry with biometric" depending on policy.
  • If salvageable (partial parse), only restore non-PII with explicit user consent.

Implementation notes (Kotlin-style pseudocode)

val envelope = readFile()
if (!verifyMagic(envelope.header)) throw CorruptException()
val dek = unwrapDEKFromKeystore()
val plaintext = AEAD.decrypt(dek, envelope.ciphertext, associatedData = envelope.headerBytes)
val state = parseByVersion(plaintext, envelope.version)
val migrated = migrateToCurrent(state)

Trade-offs

• Hardware-backed keys increase protection but complicate backups/device transfer; choose per-app policy.
• Eager rotation re-encrypts immediately; lazy rotation defers cost but leaves old DEK briefly valid.

This design ensures confidentiality, integrity, controlled key lifecycle, explicit schema evolution, and robust UX paths for corruption or version mismatch appropriate for mobile apps.

Direct answer
Coaching a genuine underperformer starts with diagnosing why (skill gap, unclear expectations, motivation, or something outside work like a health or personal issue) before assuming it's a will problem, then moving to a private, honest conversation with specific examples, a written and time-bound improvement plan with objective checkpoints, and a clear, stated understanding of what happens if the bar still isn't met. The hard part isn't the first conversation, it's staying honest and consistent through every checkpoint after it.

Structured elaboration

Diagnose before you coach

Below-the-bar performance has different root causes that call for different responses:

• Skill gap: they don't yet know how to do the thing. Response: targeted teaching, pairing, smaller scoped tasks.
• Unclear expectations: they don't know what "good" looks like here. Response: make the bar explicit and concrete, with examples.
• Motivation or engagement: they can do it but aren't. Response: a more direct conversation about what's changed and why.
• Something outside work: a health issue, a personal crisis, burnout. A private, non-judgmental check-in on wellbeing belongs early in this process, both because it's the right thing to do and because it changes what the right intervention is (support and possibly a formal accommodation, not a performance plan).

Getting this wrong (coaching a skill gap like it's a motivation problem, or the reverse) wastes the improvement window on the wrong intervention.

The conversation and the plan

• Deliver the message privately, plainly, and with specific examples: what's below the bar, what the bar actually is, and why it matters.
• Put the plan in writing: two or three concrete, observable goals, a defined timeframe, and what evidence would count as "met."
• Set a regular check-in cadence shorter than your normal 1:1 rhythm; below-the-bar performance needs tighter feedback loops, not the same cadence as everyone else.

When to involve HR formally

This is a judgment call many candidates get wrong by either never mentioning HR (naive) or looping HR in immediately (overcautious, and it can undermine trust). A reasonable line: loop in HR or your manager as soon as the conversation could plausibly lead to a formal employment outcome (a documented warning, or separation), even if you're optimistic it won't get there, because that's exactly when documentation and process need to be right from the start rather than reconstructed after the fact.

Protecting the team

The rest of the team usually already knows something is off; silence reads as either denial or unfairness. Without disclosing private performance details, it's reasonable to acknowledge you're aware of the gap and are addressing it, and to be transparent about redistributing work if needed, so the team doesn't quietly conclude the issue is being ignored.

Worked example

Situation

An engineer on a team I was supporting had been reliably strong for over a year, then their output quality and delivery reliability dropped off sharply over a couple of months: reviews were taking longer, deadlines were slipping, and the pattern didn't match a normal bad sprint.

Diagnosis

Before assuming a motivation problem, I had a private, low-pressure conversation focused on checking in rather than accusing. That surfaced that part of the issue was a skill gap on a newer part of the codebase they'd been assigned to without much ramp-up, but there was also something going on outside work affecting their focus.

Action

We set a short, explicit improvement plan: two concrete, observable goals tied to real upcoming work, a shorter check-in cadence, and pairing time on the unfamiliar codebase area. I also made sure they knew about the option to talk to HR about support resources for the personal situation, kept separate from the performance conversation so the two didn't get conflated.

Result

Performance recovered within the plan's window once the skill gap closed and the external situation stabilized. Because the conversation started from genuine diagnosis rather than an assumption, the plan addressed the actual cause instead of just adding pressure, and the person stayed on the team and rebuilt trust with the group.

The other branch (when it doesn't turn around)

Not every case ends this way. When someone doesn't meet a documented plan's criteria despite real support, the path is a harder, well-documented conversation, formal HR involvement, and eventually separation if there's no path forward. The mentor's job at that point shifts from "close the gap" to making sure the process is fair, well-documented, and handled with dignity, and to being honest with the rest of the team (without violating privacy) that a change is coming so it doesn't land as a surprise.

Trade-offs & pitfalls

• Treating every case as a motivation problem. The single biggest junior mistake here is skipping diagnosis and going straight to "try harder" messaging, which fails skill-gap and external-cause cases and can be actively harmful if there's something like burnout or a health issue underneath.
• Involving HR too late (or too early). Too late, and you've lost the documentation trail that protects everyone, including the underperformer, if it does become formal. Too early or too visibly, and it can read as punitive before the person's had a real chance, damaging trust unnecessarily.
• Optimizing for the individual at the team's expense, or the reverse. A senior answer holds both: real support for the person, and honesty with the team about workload and timeline impact, rather than pretending nothing's happening.
• No exit criteria stated up front. A plan without a clear "what does not-met look like, and what happens then" isn't actually a plan, it's a delay, and it's unfair to the person because they don't know what they're actually being measured against.

Direct answer

A high-quality test fails when, and only when, the behavior it's supposed to protect actually breaks. A brittle test fails for unrelated reasons, a refactor, timing, execution order, and a misleading test passes even when the behavior is broken. Reviewing test code means checking specifically for those two failure modes, not just confirming a test exists.

Structured elaboration

Worked example

A PR adds a test for a discount-calculation function. Weak version: assert calculate_discount(100, 0.1) is not None, which passes even if the discount math is completely wrong, as long as something is returned. Strong version: assert calculate_discount(100, 0.1) == 90, which fails immediately if the discount logic is wrong, plus a boundary case, calculate_discount(100, 0) == 100. Tracing it: if the discount subtraction were removed entirely (the function just returned the input unchanged), the weak assertion would still pass, but the strong one would fail right away, confirming the strong version actually tests the behavior it claims to.

Trade-offs and pitfalls

Line-by-line scrutiny of every test on every PR isn't realistic; prioritize new business logic and edge cases, and be more lenient on straightforward tests for simple getters and setters. A common wrong turn is treating "there's a test" as sufficient without checking whether it would actually catch a real regression, which is the same blind spot a raw test-coverage percentage has, since a line can be "covered" by a test that never meaningfully asserts anything about it.

Why stateless helps scale mobile backends
Stateless services don’t store client session/data on the app server, so any instance can handle any request. For mobile apps with many short-lived API calls (auth, sync, analytics), stateless design enables horizontal scaling, simpler deployments, faster recovery, and easier A/B rollouts.

Role of components

• Load balancers: distribute incoming mobile requests across healthy instances; perform SSL termination and path/rate routing so clients don’t need to know instance topology.
• Autoscaling groups: add/remove stateless instances based on CPU, request rate or custom metrics (e.g., requests/sec from mobile users) to match demand and control cost.
• Health checks: LB + ASG probes (HTTP/ICMP) ensure traffic goes only to healthy nodes; unhealthy instances are replaced automatically, keeping user experience stable.

Example stateful component and isolation

• WebSocket server for real-time chat/notifications is stateful (maintains connections). I’d isolate it into its own service/cluster with:
  • A dedicated autoscaling group tuned to connection count (scale by active sockets).
  • A sticky-aware load balancer or a routing layer (e.g., a message router like HAProxy or NGINX with consistent-hash) so reconnects hit the same process when needed.
  • Shared state in Redis (presence, user->server mapping) and a pub/sub (Redis Pub/Sub or Kafka) to fan out messages across instances.
  • Health checks that verify socket accept loop and Redis connectivity; on failure, reassign users via Redis mapping and rely on clients to reconnect with exponential backoff.

This pattern keeps core APIs elastic and simple for mobile clients while handling connection state in a specialized, scalable service.