DEV Community

Cover image for Android System Design: A Practical Guide for Senior Android Engineers
Padmakar Android
Padmakar Android

Posted on

Android System Design: A Practical Guide for Senior Android Engineers

#android #kotlin #architecture #systemdesign

Learn how to design production-ready Android systems with scalable architecture, offline-first data, networking, synchronization, security, performance, and real-world examples.

Introduction

Modern Android development is no longer only about building screens and connecting APIs.

As an Android application grows, engineers need to think about:

  • Scalability
  • Reliability
  • Offline support
  • Data synchronization
  • Networking
  • Caching
  • Security
  • Performance
  • Background processing
  • Real-time communication
  • Modularization
  • Maintainability

A production Android system is a combination of the mobile client, backend services, data stores, networking layer, and operational infrastructure.

This article explains how to approach Android system design from a senior mobile engineer's perspective.

What Is Mobile System Design?

Mobile system design is the process of designing the complete architecture of a mobile system and understanding how its components communicate.

A simplified production architecture looks like this:

                         Android Application
                                  |
        -------------------------------------------------
        |                    |                          |
    Compose UI           Local Storage              Network
        |                    |                          |
    ViewModel              Room                    Retrofit
        |                    |                          |
     UseCase                 |                     API Gateway
        |                    |                          |
    Repository ------------- | -------------------------
        |                                               |
        |                                  -------------------------
        |                                  |          |            |
        |                               Auth       Chat         Media
        |                              Service    Service       Service
        |                                  |          |            |
        |                                  |       Redis          CDN
        |                                  |          |
        |                                  |      Database
        |                                  |
        ---------------------- Backend -----------------------------
Enter fullscreen mode Exit fullscreen mode

The important idea is that Android is one part of the overall system.

HLD vs LLD

System design generally involves two important levels.

                         SYSTEM DESIGN
                              |
                 --------------------------
                 |                        |
                HLD                      LLD
                 |                        |
          High-Level Design        Low-Level Design
                 |                        |
          Components              Classes
          Services                Interfaces
          APIs                    Methods
          Databases               Models
          Cache                   Patterns
          Communication           Concurrency
          Scalability             Error handling
Enter fullscreen mode Exit fullscreen mode

HLD — High-Level Design

HLD answers:

What are the major components and how do they communicate?

Example:

Android App
     |
     +---- REST API ------> API Gateway
     |
     +---- WebSocket -----> Chat Service
                              |
                    --------------------
                    |        |         |
                  Redis    Database    Queue
Enter fullscreen mode Exit fullscreen mode

At HLD level, focus on:

  • System components
  • Data flow
  • API boundaries
  • Database
  • Cache
  • Message queues
  • WebSocket
  • CDN
  • Scalability
  • Availability
  • Security

LLD — Low-Level Design

LLD answers:

How will those components actually be implemented?

Example:

interface ChatRepository {

    suspend fun sendMessage(
        message: Message
    ): Result<Message>

    fun observeMessages(
        conversationId: String
    ): Flow<List<Message>>
}
Enter fullscreen mode Exit fullscreen mode

A possible implementation:

class ChatRepositoryImpl(
    private val localDataSource: ChatLocalDataSource,
    private val remoteDataSource: ChatRemoteDataSource
) : ChatRepository {

    override suspend fun sendMessage(
        message: Message
    ): Result<Message> {
        // implementation
    }

    override fun observeMessages(
        conversationId: String
    ): Flow<List<Message>> {
        return localDataSource.observeMessages(conversationId)
    }
}
Enter fullscreen mode Exit fullscreen mode

LLD focuses on:

  • Classes
  • Interfaces
  • Methods
  • Data models
  • Database entities
  • DAOs
  • Design patterns
  • State machines
  • Concurrency
  • Error handling

Android Architecture

A scalable Android application can follow a layered architecture:

                  Compose UI
                      |
                      v
                 ViewModel
                      |
                      v
                   UseCase
                      |
                      v
                 Repository
                  /       \
                 /         \
                v           v
        Local Data       Remote Data
             |                |
             v                v
           Room           Retrofit
                              |
                              v
                         Backend API
Enter fullscreen mode Exit fullscreen mode

Each layer has a clear responsibility.

Presentation

Responsible for:

  • UI
  • State
  • User interactions
  • Screen lifecycle

ViewModel

Responsible for:

  • UI state
  • Calling use cases
  • Handling screen events
  • Surviving configuration changes

UseCase

Responsible for:

  • Business rules
  • Application-specific operations

Repository

Responsible for:

  • Data coordination
  • Local/remote source selection
  • Caching
  • Synchronization

Data Sources

Responsible for:

  • Room
  • Retrofit
  • WebSocket
  • Files
  • Other external sources

Offline-First Architecture

Mobile networks are unreliable.

Users can experience:

  • No internet
  • Slow internet
  • Intermittent connectivity
  • Wi-Fi to mobile network changes
  • Background restrictions
  • Battery restrictions
  • Process death

Therefore, a production application should not assume:

Network = Always Available
Enter fullscreen mode Exit fullscreen mode

A better architecture is:

                     UI
                      |
                      v
                  ViewModel
                      |
                      v
                  Repository
                   /       \
                  /         \
                 v           v
               Room        Network
                 |             |
                 |             v
                 |           Server
                 |             |
                 +---- Sync ---+
Enter fullscreen mode Exit fullscreen mode

The local database can provide the state displayed by the UI while synchronization happens in the background.

Example: Sending a Message Offline

Suppose the user sends:

Hello
Enter fullscreen mode Exit fullscreen mode

while the device is offline.

A poor design:

User
  |
  v
API
  |
  v
Network Failure
  |
  v
Error
Enter fullscreen mode Exit fullscreen mode

A better offline-first design:

User sends message
        |
        v
Generate messageId
        |
        v
Save message in Room
status = PENDING
        |
        v
UI displays message immediately
        |
        v
Network becomes available
        |
        v
Sync Engine
        |
        v
Send API request
        |
        v
Server ACK
        |
        v
Update Room
status = SENT
Enter fullscreen mode Exit fullscreen mode

This gives the user an immediate response even when the network is unavailable.

Message State Machine

A message can be modeled as a state machine:

              +-----------+
              |  PENDING  |
              +-----+-----+
                    |
               Send Request
                    |
             +------+------+
             |             |
             v             v
          SUCCESS        FAILURE
             |             |
             v             v
           SENT          RETRY
             |             |
             v             |
         DELIVERED <-------+
             |
             v
            READ
Enter fullscreen mode Exit fullscreen mode

This approach makes retry and state transitions explicit.

Networking Architecture

A mobile networking layer should handle more than API calls.

Important concepts include:

  • HTTP
  • HTTPS
  • TLS
  • HTTP/2
  • HTTP/3
  • REST
  • WebSocket
  • Timeouts
  • Retry
  • Exponential backoff
  • Request cancellation
  • Idempotency
  • API versioning
  • HTTP caching
  • Connection pooling

A typical Android networking flow:

Compose
   |
ViewModel
   |
UseCase
   |
Repository
   |
RemoteDataSource
   |
Retrofit / OkHttp
   |
HTTPS
   |
API Gateway
   |
Backend Service
Enter fullscreen mode Exit fullscreen mode

Retry and Exponential Backoff

Not every failure should be retried.

For transient failures, an exponential backoff strategy can be used:

Attempt 1 -> 1 second
Attempt 2 -> 2 seconds
Attempt 3 -> 4 seconds
Attempt 4 -> 8 seconds
Attempt 5 -> 16 seconds
Enter fullscreen mode Exit fullscreen mode

In production systems, add appropriate limits and jitter to avoid many clients retrying at the same time.

Idempotency

Consider this scenario:

Android
   |
   | Send Message
   v
Server
   |
   | Message Created
   |
   X Response Lost
Enter fullscreen mode Exit fullscreen mode

The client does not know whether the server processed the request.

The client retries:

Android
   |
   | Send Message Again
   v
Server
Enter fullscreen mode Exit fullscreen mode

Without protection, the message could be created twice.

Use a unique operation/message ID:

messageId = UUID
Enter fullscreen mode Exit fullscreen mode

The server can recognize that the operation has already been processed.

Request 1
messageId = ABC123
       |
       v
Server creates message

Request 2
messageId = ABC123
       |
       v
Server detects existing operation
       |
       v
No duplicate
Enter fullscreen mode Exit fullscreen mode

Idempotency is one of the most important reliability concepts in mobile-to-backend communication.

WebSocket and Real-Time Communication

For real-time applications such as chat, polling is often inefficient.

Instead of:

GET /messages
GET /messages
GET /messages
GET /messages
Enter fullscreen mode Exit fullscreen mode

use a persistent connection:

Android
   |
   | WebSocket
   v
WebSocket Server
   |
   v
Chat Service
Enter fullscreen mode Exit fullscreen mode

The server can push events to the client.

WebSocket + Push Notifications

A real-time mobile system can use both WebSocket and FCM:

                     Chat System
                          |
              +-----------+-----------+
              |                       |
         WebSocket                    FCM
              |                       |
              v                       v
      Foreground App          Background Notification
Enter fullscreen mode Exit fullscreen mode

WebSocket can handle:

  • Messages
  • Typing indicators
  • Presence
  • Delivery updates

FCM can handle:

  • Background notifications
  • New message notifications
  • Events when a persistent connection is unavailable

WebSocket Reconnection

A production WebSocket client needs a connection lifecycle.

CONNECTED
    |
    v
NETWORK LOST
    |
    v
DISCONNECTED
    |
    v
BACKOFF
    |
    v
RECONNECT
    |
    v
AUTHENTICATE
    |
    v
SYNC MISSED EVENTS
    |
    v
CONNECTED
Enter fullscreen mode Exit fullscreen mode

Avoid aggressive reconnect loops.

Use controlled exponential backoff with suitable limits.

Pagination

Large datasets should not be downloaded at once.

Offset pagination:

GET /messages?page=1
GET /messages?page=2
GET /messages?page=3
Enter fullscreen mode Exit fullscreen mode

Cursor pagination:

GET /messages?before=message_987
Enter fullscreen mode Exit fullscreen mode

Cursor-based pagination can provide more stable behavior for changing datasets.

Android applications can combine this with Paging 3 and Room.

Caching

A production mobile application can have multiple cache layers:

                  Server
                    |
                    v
                 Network
                    |
                    v
              Repository
               /       \
              v         v
        Memory Cache   Room
              \         /
               \       /
                  UI
Enter fullscreen mode Exit fullscreen mode

Important concepts:

  • Memory cache
  • Disk cache
  • HTTP cache
  • Database cache
  • CDN
  • TTL
  • LRU
  • Cache invalidation
  • Cache-aside
  • Stale data

Database Design

For Android local persistence:

Room
 |
 +-- Entity
 |
 +-- DAO
 |
 +-- Database
 |
 +-- Migration
Enter fullscreen mode Exit fullscreen mode

Example:

@Entity
data class MessageEntity(
    @PrimaryKey
    val id: String,
    val conversationId: String,
    val senderId: String,
    val content: String,
    val status: MessageStatus,
    val createdAt: Long
)
Enter fullscreen mode Exit fullscreen mode

But system design also requires knowledge of:

  • SQLite
  • Indexes
  • Transactions
  • WAL
  • Query optimization
  • Database migrations
  • SQL vs NoSQL
  • Replication
  • Sharding

Background Synchronization

Offline operations can be stored in a persistent queue.

+-------------------------+
|       Sync Queue        |
+-------------------------+
| Operation 1 - PENDING   |
| Operation 2 - PENDING   |
| Operation 3 - FAILED    |
+------------+------------+
             |
             v
        Sync Worker
             |
             v
          Network
          /      \
         v        v
     SUCCESS    FAILURE
        |          |
        v          v
     Remove      Retry
Enter fullscreen mode Exit fullscreen mode

Android's WorkManager can be part of this design when work needs to continue reliably across process restarts.

Process Death

Android can kill your application process.

Never depend entirely on in-memory state for important operations.

Bad:

Upload state
     |
     v
Memory only
     |
Process killed
     |
State lost
Enter fullscreen mode Exit fullscreen mode

Better:

Upload Queue
     |
     +-- File 1 -> COMPLETE
     +-- File 2 -> COMPLETE
     +-- File 3 -> PENDING
     +-- File 4 -> PENDING
Enter fullscreen mode Exit fullscreen mode

After process recreation:

Process Starts
      |
      v
Read Persistent State
      |
      v
Find PENDING Operations
      |
      v
Resume Work
Enter fullscreen mode Exit fullscreen mode

Security Architecture

Security should be part of system design from the beginning.

A simplified authentication flow:

Android
   |
   v
Login API
   |
   v
Auth Service
   |
   +---- Access Token
   |
   +---- Refresh Token
             |
             v
       Secure Storage
Enter fullscreen mode Exit fullscreen mode

Important topics:

  • OAuth 2.0
  • OpenID Connect
  • Access tokens
  • Refresh tokens
  • Token rotation
  • Android Keystore
  • TLS
  • Certificate pinning
  • Encryption
  • Secure storage
  • R8/ProGuard
  • Device binding
  • App tampering

Performance

A scalable mobile system must also be efficient.

Consider:

Startup
Memory
Battery
Network
Database
Rendering
Background Work
Enter fullscreen mode Exit fullscreen mode

For Jetpack Compose:

State Change
     |
     v
Recomposition
     |
     v
Layout
     |
     v
Draw
     |
     v
Frame
Enter fullscreen mode Exit fullscreen mode

Important areas:

  • Recomposition
  • Stability
  • State hoisting
  • Lazy layouts
  • Baseline Profiles
  • Startup optimization
  • Memory leaks
  • ANR
  • UI jank

Scalability

Imagine an application growing:

10 users
   |
   v
10K users
   |
   v
1M users
   |
   v
100M users
Enter fullscreen mode Exit fullscreen mode

The architecture needs to evolve.

A simplified backend:

                 Load Balancer
                      |
          +-----------+-----------+
          |           |           |
          v           v           v
       Server 1    Server 2    Server 3
          |           |           |
          +-----------+-----------+
                      |
                    Redis
                      |
                      v
                   Database
Enter fullscreen mode Exit fullscreen mode

Important distributed-system concepts:

  • Horizontal scaling
  • Vertical scaling
  • Load balancing
  • Redis
  • CDN
  • Replication
  • Sharding
  • Message queues
  • Rate limiting
  • Event-driven architecture
  • Eventual consistency
  • CAP theorem

Failure Scenarios

A senior engineer should always think about failure.

Network failure 

Request
   |
Timeout
   |
Retry?
Enter fullscreen mode Exit fullscreen mode

Process death 

Process Death
     |
     v
Persisted State
     |
     v
Resume Operation
Enter fullscreen mode Exit fullscreen mode

Duplicate request 

Duplicate Request
       |
       v
Idempotency Key
       |
       v
Single Operation
Enter fullscreen mode Exit fullscreen mode

Out-of-order messages 

Expected:

A -> B -> C

Received:

B -> A -> C
Enter fullscreen mode Exit fullscreen mode

A system needs a strategy for ordering and reconciliation.

Concurrent updates 

Device A
   |
   +---- Update X

Device B
   |
   +---- Update X
Enter fullscreen mode Exit fullscreen mode

A conflict-resolution strategy is required.

Observability

Production systems need visibility into failures and performance.

Android
   |
   +-- Crashes
   +-- ANRs
   +-- API latency
   +-- Network errors
   +-- Startup time
   +-- Memory
   +-- Battery
          |
          v
      Telemetry
          |
          v
       Backend
          |
          v
      Dashboard
          |
          v
        Alerts
Enter fullscreen mode Exit fullscreen mode

Useful metrics include:

  • Crash-free users
  • ANR rate
  • API latency
  • Network failure rate
  • Startup time
  • Memory usage
  • Battery usage
  • UI jank
  • Feature adoption

A Practical System Design Checklist

When designing any mobile system, ask:

1. What are the functional requirements?

2. What are the non-functional requirements?

3. How many users do we expect?

4. Where does the data live?

5. What happens when the network is unavailable?

6. What happens when Android kills the process?

7. How does synchronization work?

8. How do we prevent duplicate operations?

9. How does the system scale?

10. How do we secure the data?

11. How do we monitor failures?

12. What are the trade-offs?
Enter fullscreen mode Exit fullscreen mode

Recommended Learning Path

For a senior Android engineer, focus on these areas in order:

Android Architecture
        |
        v
Concurrency
        |
        v
Networking
        |
        v
Database + Caching
        |
        v
Offline-First
        |
        v
Synchronization
        |
        v
Distributed Systems
        |
        v
Security
        |
        v
Performance
        |
        v
HLD
        |
        v
LLD
        |
        v
Real-World System Design
Enter fullscreen mode Exit fullscreen mode

The most important shift is to stop thinking only about:

"How do I implement this Android feature?"

and start asking:

"How will this feature behave when the network fails, the process dies, the data becomes stale, the request is duplicated, the number of users grows, and multiple clients modify the same data?"

That is the mindset of mobile system design.

Real-World Systems to Study

After learning the fundamentals, practice designing:

  1. WhatsApp-like Chat
  2. Signal-like Secure Messaging
  3. Instagram Feed
  4. News Application
  5. Uber-like Ride Sharing
  6. YouTube-like Video Streaming
  7. Food Delivery Application
  8. E-commerce Application
  9. Offline File Upload System
  10. Image Loading Library
  11. Networking Library
  12. Notification System

Conclusion

Android system design sits at the intersection of:

Android
+
Distributed Systems
+
Networking
+
Databases
+
Security
+
Performance
+
Reliability
Enter fullscreen mode Exit fullscreen mode

You don't need to become a backend engineer to become a strong mobile system designer.

You need to understand how the mobile client participates in the complete system, make appropriate architectural decisions, understand failure modes, and explain the trade-offs behind those decisions.

For senior Android engineers, that is the path from feature-level development to system-level engineering.

About the Author

Padmakar Garg is an Android developer focused on scalable mobile architecture, Kotlin, Jetpack Compose, security, performance, and production-grade Android systems.

Top comments (0)