Article · System design

Mobile System Design: A Practical Guide for Android Engineers

A mobile system design question is not a backend question with a phone drawn on the left. The phone is a small, unreliable computer that is often offline, runs on a battery, can be killed at any moment and is shipped as a binary you cannot patch tomorrow. This article gives you a repeatable way to design for those facts, with a step-by-step framework, the building blocks, and three worked designs.

1. What makes mobile system design different

Backend design asks: how do we serve a million requests per second? Mobile design asks a different question: how does one phone give one person a fast, correct, battery-friendly experience on a bad network? The server still matters, but the client is where most of the interesting trade-offs live.

2. A six-step framework

Use the same order every time. It keeps you from jumping to a favourite library before you know the problem.

3. Step 1: Requirements and constraints

Functional requirements

List what the user can do, in a few short sentences. For a feed app: “see a feed, scroll forever, like a post, create a post with a photo, get notified of replies.” Mark which of these must work offline.

Non-functional requirements

These decide the design. Ask about each one, and write a number when you can.

4. Step 2: The API between app and server

The app and server meet at the API. A mobile-friendly API is shaped by the screens, not only by the database.

Design rules for a mobile API

• Pagination, not “get all”. Prefer cursors (“give me 20 items after this token”) over page numbers, because items are inserted while the user scrolls.
• Idempotency keys for writes. The app may retry a request after a timeout. A unique key per action lets the server ignore the duplicate.
• Versioning and compatibility. Old app versions live for months. Add fields; do not remove or rename them. Return a minimum-supported-version signal so you can force an upgrade as a last resort.
• Small payloads. Compress (gzip or brotli), return only the fields the screen needs, send image URLs with size hints rather than full images.
• Conditional requests. Use ETag or If-Modified-Since so unchanged data costs a tiny 304 response.
• Clear errors. Return a machine-readable code, so the app can tell “retry later” from “you must log in” from “this will never work”.

GET  /v1/feed?limit=20&cursor=eyJ0IjoxNzI5...      -> { "items": [...], "nextCursor": "eyJ0Ijox..." }
POST /v1/posts          Idempotency-Key: 7f3c-...    -> 201 { "id": "p_91" }
POST /v1/posts/p_91/like   Idempotency-Key: a12b-... -> 200 (second call returns the same result)

5. Step 3: Data model and local storage

Decide what lives on the phone, in what shape, and who is the owner of each piece of data.

Separate the models

Keep three shapes of the same thing and convert between them at the edges. It lets the server, the database and the UI change independently.

// What the server sends (network model)
@Serializable data class PostDto(val id: String, val text: String, val authorId: String, val createdAt: Long)

// What the database stores (entity)
@Entity data class PostEntity(@PrimaryKey val id: String, val text: String, val authorId: String,
                              val createdAt: Long, val syncState: Int /* 0 synced, 1 pending, 2 failed */)

// What the screen needs (UI model)
data class PostUi(val id: String, val text: String, val timeAgo: String, val isPending: Boolean)

6. Step 4: Client architecture

Keep three layers: a UI that shows state, a domain layer with the rules, and a data layer that hides where data comes from. This is the View, Logic, Data idea from my architecture series, and the repository is the glue.

Choices to state out loud

• Presentation pattern: MVVM with a single state object, or MVI when you want strictly one-way flow. See MVVM and Redux.
• Dependency injection: Hilt or Koin so layers can be replaced in tests. See DI, async and errors.
• Concurrency: coroutines and Flow, with the main thread kept free for drawing.
• Modularization: split into feature and core modules once the team or build time grows. See VIPER and modules.
• Navigation and deep links: one place that maps a URL or notification to a screen.

class FeedRepository(private val dao: PostDao, private val api: FeedApi) {

    // The UI observes this. It never reads the network directly.
    fun feed(): Flow<List<Post>> = dao.observeAll().map { rows -> rows.map { it.toDomain() } }

    // Called on open, pull to refresh, or by a background worker.
    suspend fun refresh(): Result<Unit> = runCatching {
        val page = api.feed(limit = 20)
        dao.upsertAll(page.items.map { it.toEntity() })
    }
}

7. Networking building blocks

Caching: layers, from fastest to slowest

Common cache policies: cache-then-network (show stored data now, refresh in the background), stale-while-revalidate (use stale data and update it silently), and network-first with fallback (for data that must be fresh, such as a balance).

Retries: exponential backoff with jitter

If a request fails because of a timeout or a 5xx error, wait and try again, with the wait doubling each time and a little randomness so a million phones do not retry at the same instant. Do not retry client errors such as 400 or 403; they will never succeed. Only retry writes that are idempotent.

suspend fun <T> retryWithBackoff(times: Int = 4, base: Long = 500, block: suspend () -> T): T {
    var delayMs = base
    repeat(times - 1) {
        try { return block() } catch (e: IOException) { /* transient: fall through and wait */ }
        delay(delayMs + Random.nextLong(0, delayMs / 2))      // jitter
        delayMs *= 2
    }
    return block()                                            // last attempt: let the error out
}

Pagination

Load the first page fast, load the next when the user is near the end, and keep the pages in the database so scrolling back is instant. On Android, Paging 3 with a RemoteMediator does exactly this. A cursor beats an offset, because an offset shifts when new items appear at the top.

Images

• Use a proven loader (Coil, Glide) rather than writing your own. It gives you memory and disk caching, request cancellation when a row scrolls away, and downsampling.
• Ask the server or CDN for the size you need (thumbnail versus full), and a modern format such as WebP or AVIF.
• Show a small placeholder (a blurred preview or a colour) so layout does not jump.

Real-time and push

Background work

Use WorkManager for deferrable, guaranteed work (upload a photo, sync when the network returns), with constraints such as “connected” and “not low battery”. Use a foreground service only for work the user is actively aware of (navigation, a call, a download).

8. Offline-first and sync

Offline-first means the app works from its local data and treats the network as a background sync. Reads come from the database; writes go to the database first, then to the server.

The outbox pattern

Store every outgoing change in a table (or the pending rows themselves). A background worker drains it in order. Because each item has a stable id, a crash or a retry cannot send it twice with a different effect.

Conflicts: what if two devices edit the same thing?

9. Performance, battery and memory

Set budgets, then measure

Radio and battery

The mobile radio stays in a high-power state for a while after each request. Ten small requests spread over ten minutes cost much more battery than one request carrying the same data. Group non-urgent work and let the system choose the moment.

Lists

Long lists are the most common performance problem. Use lazy lists (LazyColumn or RecyclerView), give items stable keys, keep item layouts shallow, load images asynchronously and avoid doing heavy work in the binding code.

10. Security and privacy

• The client is not trusted. Authorization, price calculation and validation are decided on the server. Client checks are only for user experience.
• Transport: HTTPS only; consider certificate pinning for high-risk apps, with a plan for rotating certificates.
• Authentication: short-lived access tokens plus a refresh token held in the Keystore. Refresh once and queue other requests while it happens. On refresh failure, send the user to sign in.
• Data at rest: keep as little as possible; encrypt sensitive data; clear it on sign-out.
• Secrets: never ship API secrets in the app. Anything in the binary can be extracted.
• Privacy: ask for permissions at the moment they are needed, explain why, honour consent and deletion requests, and avoid logging personal data.
• Hardening: R8 obfuscation slows reverse engineering; Play Integrity checks help with abuse, but neither replaces server-side checks.

11. Release, flags and observability

Because you cannot instantly fix a shipped app, the system around the code matters as much as the code.

12. Three worked designs

A. A social feed (Instagram or X style)

Requirements: infinite scroll, like, post with photo, notifications. Stale data for a few minutes is fine. Posting should work offline.

• API: cursor-paginated GET /feed; idempotent POST /posts and POST /likes; images served from a CDN with several sizes.
• Data: Room tables for posts, users and a remote-keys table for paging. Paging 3 with a RemoteMediator loads from the network into the database; the UI reads from the database.
• Likes: optimistic update. Flip the heart at once, queue the request, and revert with a short message if it finally fails. Keep a counter that the server owns, so retries do not double-count.
• Posting a photo: save to the database with syncState = PENDING, compress the photo on a background thread, upload in chunks with WorkManager (resumable), then attach the media id to the post request.
• Images: Coil with disk and memory caches, thumbnails in the list and the full size in the detail screen, blurred placeholder.
• Freshness: pull to refresh, refresh on open if the last sync is older than a few minutes, and a push notification only for important events.
• Trade-off: showing cached content fast means a small risk of stale items; mark them softly (a “new posts” pill) rather than reordering under the user’s thumb.

B. A chat app (WhatsApp style)

Requirements: one-to-one and group chat, delivery and read status, works offline, history is stored on the phone, messages must never be lost or duplicated.

• Transport: a persistent WebSocket while the app is in the foreground; FCM high-priority push when it is not. The push only says “you have a new message”, and the app then syncs.
• Message identity: the client generates a unique id (a UUID) for each message. The server stores it, so a retry cannot create a duplicate. The server adds an increasing sequence number per conversation for ordering.
• Local database: conversations, messages (with state: sending, sent, delivered, read, failed), participants. The chat screen observes a query for one conversation, ordered by sequence number and then by local time.
• Send flow: write the message as sending to the database, show it immediately, hand it to the socket (or the outbox worker when offline), and update to sent when the server acknowledges.
• Reconnect: the app tells the server the last sequence number per conversation it has and receives anything newer.
• Receipts and typing: small events over the socket; typing indicators are not stored. Batch read receipts so opening a long chat sends one message, not hundreds.
• Media: upload separately and send only a reference; encrypt end to end if required, with keys in the Keystore.
• Trade-off: a permanent connection gives instant messages but costs battery, so close it when the app goes to the background and rely on push.

C. A ride or delivery tracking screen

Requirements: show the driver’s position moving on a map in near real time, with a changing ETA, on mobile networks that drop out.

• Updates: subscribe to a stream (WebSocket or gRPC streaming) while the screen is visible; unsubscribe when it is not. Send small position messages (id, latitude, longitude, heading, timestamp).
• Smoothness: positions arrive every few seconds, so the app animates between them (interpolation) and snaps to the road. Ignore out-of-order messages by timestamp.
• Resilience: on reconnect, fetch the latest state first and then resume the stream. Show “last updated 20 s ago” when the stream is silent.
• The rider’s own location: use the fused location provider with a balanced accuracy, a foreground service while a trip is active, and lower frequency when the phone is still, to save battery.
• Maps: load only the visible area, cluster markers, and cap the number drawn.
• Trade-off: higher update frequency looks smoother but costs data and battery; pick the lowest rate that still feels live.

13. Classic system design lessons, seen from the phone

Well-known system design courses (the Grokking series, for example) teach the back end: estimation, building blocks and case studies. I have not copied any course; the tables below are my own summary of the usual topics, and a full course is the place to go deep on the server side. Every one of these ideas still shapes a mobile design, because the app is the first component in that picture.

The RESHADED approach, mapped to this article

The course ends with a named approach for tackling a design problem. As I understand it, the letters stand for Requirements, Estimation, Storage schema, High-level design, API design, Detailed design, Evaluation and Distinctive component or feature. It lines up with the six steps in section 2:

Back-of-the-envelope estimates

Estimate first; it tells you whether you need a cache, a CDN or sharding. Use round numbers and show the arithmetic.

Feed app, 10 million daily users, 20 feed requests per user per day
  requests per day     = 10M x 20            = 200M
  average per second   = 200M / 86,400       = about 2,300 requests/s
  peak (3x average)                          = about 7,000 requests/s

  one feed page        = 20 items x 1 KB     = 20 KB (JSON, before compression)
  traffic per second   = 2,300 x 20 KB       = about 46 MB/s   -> use a CDN and compression

On the phone: 100 posts cached x 1 KB = 100 KB of rows (tiny);
              100 thumbnails x 30 KB   = 3 MB on disk        (set a disk-cache limit)

Non-functional characteristics

Building blocks and where the app touches them

Classic case studies and the mobile angle

14. Common mistakes and a checklist

Mistakes to avoid

• Reading the network directly from the UI, so the screen is blank offline.
• Keeping the only copy of data in memory or in a ViewModel.
• Retrying everything, including non-idempotent writes and permanent errors.
• Polling every few seconds instead of using push or a long interval.
• Loading full-size images into small views.
• Breaking old app versions by changing or removing API fields.
• Shipping a risky feature with no flag and no staged rollout.
• Trusting the client for permission checks.
• Designing only the happy path: no loading, empty, error, offline or partial states.

Design-review checklist

15. Takeaways

• Start from the user’s experience and the phone’s limits, then design the API, data and architecture to fit.
• Make the local database the source of truth; the network is a background sync.
• Be defensive about the network: paginate, cache, batch, back off with jitter, use idempotency keys.
• Set budgets for start time, frame time, memory, battery and data, and measure them in the field.
• Plan for what you cannot undo: backward-compatible APIs, feature flags, kill switches and staged rollouts.
• Always say the trade-off out loud. A design without a stated cost is not finished.