Design patterns in mobile system design rounds (Android and iOS)

How to read this. Patterns are vocabulary. They are not answers. In a round, state the problem first, then say the pattern name in one short phrase. This page lists the patterns that the rounds on this site use, and where each one appears. The platform sections near the end cover patterns that Android and iOS use a lot, such as delegation.

TL;DR. Eleven patterns cover most of the mobile design rounds here. Four of them carry the most weight: state machine, outbox, repository and idempotency key. Each round now shows the patterns it uses at the top.

The patterns at a glance

The eleven patterns

State machine

The problem. A flow has many steps, retries and interruptions, and flags allow impossible mixes.

The shape. List every state the flow can be in, and every event that can move it. One pure function maps a state and an event to the next state and a list of effects.

On a phone. The process can end between two states. Save the states that cost money, and start from a state that asks the server, not from the first screen.

Where it breaks. The list grows past about ten states. Split it into nested machines.

Where it appears.

• Design a state machine for a mobile flow: the checkout is a closed list of states and events.
• Design a hotel or ride booking app: the booking moves through states that the server owns.
• Design a video streaming app: playback state is one of the things the case covers.
• Design a pagination library: each direction has its own load state.

Say this. "I write the states and events first, so a double tap has one answer."

Outbox

The problem. The user acts on a bad link, and the action must not be lost or sent twice.

The shape. Write the intent to a local table in the same transaction as the local change. A worker sends the rows in order and marks one done when the server confirms.

On a phone. A scheduler runs the sender: WorkManager on Android, or a background task on iOS. The process can die after the send and before the answer, so the row carries a key that makes a retry safe.

Where it breaks. Rows that depend on each other need an order. A queue that never drains needs a visible failed state.

Where it appears.

• Design a chat app: a send is a pending row that a worker delivers.
• Design a news feed: a like is saved first and sent later.
• Design a travel plans app: an edit made offline waits in a queue.
• Design an analytics SDK: events are saved to disk and sent in batches.
• Design photo backup and file sync: an upload is a saved job that can resume.

Say this. "The tap writes a row. A worker sends it. A key makes the retry harmless."

Repository (single source of truth)

The problem. The network, the cache and the screen disagree about what the data is.

The shape. One class owns where a type of data comes from. The screen reads the local copy, and the network writes into it.

On a phone. Screens are recreated all the time. The local copy survives them, so the screen can draw at once and update when the network answers.

Where it breaks. Two places write the same data, or the repository only forwards calls and decides nothing.

Where it appears.

• Design a chat app: the on-device database is the one copy the app trusts.
• Design a news feed: the screen reads the saved page, and the network writes into it.
• Design a stock ticker app: a quote repository is the way in, and ticks stay in memory because writing each one to the database costs too much.
• Design a pagination library: an optional mediator writes network pages into a local database that is the source of truth.

Say this. "The screen reads one copy. The network updates that copy."

Observer (a stream of values)

The problem. Many screens need the latest value without asking again and again.

The shape. A source publishes values. Any number of readers receive the newest one.

On a phone. Collect only while the screen is visible. Decide how often the screen redraws: a stream that emits every tick and redraws every tick wastes battery.

Where it breaks. A stream with no limit on its rate. Pair it with coalescing.

Where it appears.

• Design a stock ticker app: the screen collects a stream of prices.
• Design a chat app: the screen watches the database.
• Design a state machine for a mobile flow: the screen draws the state and sends events.
• Design a pagination library: the library gives the caller a stream of states.

Say this. "The screen collects the latest value, and only while it is on screen."

Facade and adapter

The problem. A vendor library or a messy engine should not leak into the rest of the app, or into other developers' apps.

The shape. A facade gives one small front to a bigger engine. An adapter turns a vendor API into the interface you want.

On a phone. An SDK author cannot see the host app, and every public name is a promise for years. Keep the public surface small, and keep the engine private.

Where it breaks. An interface that copies the vendor one to one, so a vendor change still reaches every caller.

Where it appears.

• Design feature flags and remote config: the vendor sits behind a small flag interface.
• Design a pagination library: a small public core hides a private engine.
• Design an analytics SDK: the public API is only track, identify and flush.
• Design a push notification SDK: the SDK keeps one record and the host app keeps the screens.
• Design an image loading library: a request object and one loader hide caches, decoding and cancelling.

Say this. "The app talks to my small interface. The vendor is behind an adapter."

Strategy

The problem. The same step must behave differently by situation, and the choice should be easy to swap.

The shape. Put one decision behind a small interface, so a different rule can be swapped in without changing the caller.

On a phone. The right rule depends on the phone: the network, the battery, the foreground. Examples are when to apply new values, or how long to wait before a retry (see the retry explorer).

Where it breaks. The caller picks the rule with an if-chain, so the strategy is only a name.

Where it appears.

• Design feature flags and remote config: when new values apply: at the next start, or live for a kill switch.
• Design a pagination library: the caller supplies the page source.

Say this. "The rule for when new values apply is separate from the code that applies them."

Coalescing

The problem. Duplicate or very frequent work should become one piece of work.

The shape. Merge duplicate or very frequent work into one piece of work.

On a phone. Lists ask for the same image many times while the user scrolls. A feed of prices changes faster than the screen can draw. One shared download, or one newest value, saves memory and battery.

Where it breaks. When order matters, such as chat messages, merging loses information.

Where it appears.

• Design an image loading library: identical requests share one download.
• Design a stock ticker app: only the newest tick for each symbol is drawn.

Say this. "Identical requests share one download. I draw the newest tick, not every tick."

Memento (saved progress)

The problem. The system ends the process in the middle of a task.

The shape. Keep a small record that lets a task resume, or lets the app check what happened.

On a phone. Where the record lives decides if it survives. A small saved state can vanish when the user swipes the app away. A database or a file survives. The state machine build guide shows the difference.

Where it breaks. Saving too much, or saving after the request has already left.

Where it appears.

• Design a state machine for a mobile flow: the attempt id is saved before the payment leaves.
• Design photo backup and file sync: saved progress means a killed app loses at most one block.
• Design a hotel or ride booking app: one saved attempt and a key survive an interruption.

Say this. "I save the attempt before I send it, so a killed app can ask what happened."

Scoped owner (the careful singleton)

The problem. Some objects must outlive screens: a player, a flag store, an image loader.

The shape. One instance owns a resource for as long as the app runs. It is created at app start and passed in, not reached through a global.

On a phone. A screen can be destroyed at any time. A player, a flag store or a payment call must not die with it.

Where it breaks. Hidden global state that no test can replace.

Where it appears.

• Design feature flags and remote config: one store lives as long as the app.
• Design a video streaming app: the player is owned outside any screen, by a service, because the case rejects a plain singleton.
• Design an image loading library: one loader is shared by every screen.

Say this. "One store lives as long as the app, and screens take a view of it."

Idempotency key

The problem. A retry must not do the work twice.

The shape. The client makes a unique id before the first send. The server keeps the result for that id and returns it again for a repeat.

On a phone. Make the id and save it before the request leaves. After a kill, the id is what lets the app ask what happened. See idempotency keys on mobile.

Where it breaks. The same key with different data, or a key that the server has already forgotten. Stripe, for one, may prune keys after at least 24 hours.

Where it appears.

• Design a hotel or ride booking app: the key is made before the first send.
• Design a chat app: a client-made ID makes a repeat harmless.
• Design a state machine for a mobile flow: the attempt id is the key.
• Design an analytics SDK: the server removes repeated events.

Say this. "The phone makes the key before the first send, so a retry counts once."

Layered cache

The problem. The network is slow or missing, and the app should still show something true.

The shape. Keep the data in layers, such as memory, disk and network. Read the nearest layer first.

On a phone. The network may be missing for hours. Show the saved copy at once, say how old it is, and replace it when fresh data arrives.

Where it breaks. A key made only of the URL, or stale data shown with no age.

Where it appears.

• Design an image loading library: memory, then disk, then network, with keys made of source, size and transforms.
• Design feature flags and remote config: a saved copy that is read before the network.
• Design a public transport app: a timetable file that is swapped whole.
• Design a news feed: the saved page is shown first.

Say this. "The screen shows the saved copy with its age, and the network replaces it."

Patterns that each platform uses a lot

The general patterns above sit on top of habits that each platform has. An interviewer who works on one platform will listen for them. The rows say which general pattern each platform habit is, and which round shows it.

Android

iOS

How does the code report back? Four options

This is a question you meet when you design an SDK, and when you explain one in a round. This table is my own guidance, not an Apple or Google rule.

The choice matters in an SDK because the host app lives for years. A delegate or a callback interface is easy to read in a stack trace. A stream is easy to combine. A closure per call is the lightest. I would say which one I pick and why, and that I keep it the same across the SDK.

How to talk about patterns in a round

• Problem first, name second. "A retry could charge twice, so the phone makes a key first. That is an idempotency key." The other order sounds like a recitation.
• One sentence of cost. Every pattern costs something. Say it: a state machine costs a longer list of states, an outbox costs a queue that can stall.
• Use the platform word too. "A ViewModel holds the state, and it is a state machine" shows that you know both.
• Do not stack patterns. Three patterns on one box is a sign that none of them is doing work.

Common weak answers. Naming a pattern before there is a problem. "I would use a singleton" with no word on how it is created or replaced in a test. A repository that only forwards calls. An observer with no rate limit. These repeat across public prep material. They are not a dataset.

Further reading (official docs)

• Android app architecture guide
• Android persistent work
• Apple delegation (retired archive page)
• Apple NotificationCenter
• Idempotency keys on mobile
• WorkManager vs BGTaskScheduler