Master distributed systems
& client-side engineering.

Design a forecast app like the Google or Apple weather app - one screen for the current location, a forecast that loads instantly from cache, an honest offline state, and a constrained background refresh.

Why offline is the mobile design problem, and the sync and conflict strategies every system-design loop probes the moment the network drops.

A sampling profiler captures call stacks at fixed intervals. Convert those snapshots into start/end span events. Three phases - basic diff, recursion, then a min-consecutive-count debounce.

Stack-walk a bracket string to validate it, then localize the first error, then find the longest valid substring (LC 32).

Why a screen that ignores semantics and locale reads as broken to a chunk of your users, and the parts an interviewer expects you to name when "accessibility" or "i18n" comes up.

Why "it works on my device" is not a shippable answer, and the version-gating strategy that keeps one codebase correct across a decade of Android releases.

Why every megabyte you ship costs install rate and startup time, and the delivery pipeline an interviewer probes when "app size" or "cold start" lands on the table.

Clean Architecture layers, MVVM vs MVI, the Repository observe/refresh split, the three types of data operations, and Use Cases - the architecture vocabulary every mobile system-design panel listens for.

Why work you start after the user leaves the screen has to be scheduled, not threaded, and the OS constraints that decide which scheduler a given job earns.

Why the build is an architecture decision - the module graph and tooling knobs that decide whether a team ships weekly or watches CI all day.

HTTP cache semantics, in-memory and disk LRU, CDN tiers, stale-while-revalidate, and invalidation patterns - the layered cache model every mobile app inherits.

Jetpack Compose's declarative model, recomposition rules, and the stability / state APIs that separate a fast Compose UI from a janky one.

Coroutines, structured concurrency, and Flow - Kotlin's concurrency model on Android, with the cancellation and scoping rules that keep work from leaking.

Why the wiring between your layers is a build-time contract, not a runtime guess - and the scopes that keep a Singleton from leaking a screen's state across the app.

The Android frame pipeline - main thread to RenderThread to SurfaceFlinger to display - plus Compose phases, Hardware Composer fallback, and how WebView's parallel pipeline meets up at the compositor.

Why loading an image is a memory and decode problem, not a network call - and the pipeline decisions that keep a thousand-cell grid from OOMing a mid-range device.

Why an Android app with more than one process or a cross-app surface needs the IPC primitives, and which one each system-design shape reaches for.

Why a memory budget is a design constraint - and how GC pauses may cause dropped frame.

The map of the Core Concepts catalog - the subjects, the order they depend on, and the two ways to read them.

Start here, what's important to demonstrate during mobile system design interview, the rubric the panel grades against, and types of such interviews.

Compose Navigation - NavController, type-safe routes, back stack mechanics, deep links, and per-destination ViewModel scoping. The contract every multi-screen Android app builds on top of.

When reaching for C/C++ on Android earns its complexity, and the JNI and ABI constraints that decide whether a native dependency ships at all.

Why the transport you pick shapes latency, reconnection, and battery - and the protocol an interviewer expects you to justify for any live or streaming surface.

Why an infinite scroll needs a cursor and a cache, and the pagination pattern that keeps a feed stable and smooth under inserts.

Why a performance claim without a measurement is a guess, and the tools an interviewer expects you to reach for when a frame budget or startup target is on the line.

Why "where does this state live when the process dies" is a design question, and the persistence decision tree that keeps data safe, fast, and recoverable.

Activity / Fragment / Service lifecycles, Application + ProcessLifecycleOwner, the ART runtime, and the OS-level constraints (process model, Doze, App Standby) every modern Android API assumes you understand.

Why push is a wakeup signal, not a data channel - and the FCM + notification rules that keep a background app responsive without burning battery.

Why a sensitive feature without the platform's crypto and attestation primitives is a liability, and the security seams an interviewer probes for anything touching tokens, keys, or user data.

Why "who owns the state and what survives rotation" is the question every screen has to answer, with SSOT and UDF as the named principles, the two kinds of state holder, one-shot events as state, and the survival ladder - ViewModel, SavedStateHandle, rememberSaveable - that tells you which surface keeps each piece of state alive.

The Android test pyramid in practice - JVM unit tests, Robolectric on the JVM, instrumentation on a device, plus the doubles and screenshot tools that make the layers work.

Why embedding web content inside an Android app is a security and performance decision, and the seam an interviewer probes when "show this web page" lands in a design.

The 90% every concrete app design shares - the Compose + ViewModel + Flow + Room + Hilt skeleton to know and reuse.