0% completed
Mobile System Design vs Backend System Design
On This Page
- Compare the main responsibilities
- Use one example: accepting a delivery order
- Confirm what the interview includes
- Explain the same action from both sides
- A timeout does not always mean failure
- Decide which data must remain after the app stops
- Separate local display data from shared decisions
- Keep the interface responsive
- Limit unnecessary network and background work
- Support different installed versions
- Connect requirements to decisions
Practice questions
Takeaway
Mobile system design and backend system design describe different parts of the same product.
Mobile system design focuses on the app running on a device. It explains what the user sees, what the app saves, and how it behaves when the connection fails or the app's process stops.
Backend system design focuses on software running on servers. It explains how the system manages shared data, applies rules across users, and handles requests from many devices.
Both need security, reliability, and good performance. The difference is where you make the decisions.
1. Compare the main responsibilities
| Topic | Backend design | Mobile design |
|---|---|---|
| Main goal | Serve many users and apply shared rules correctly. | Provide a useful, responsive experience on each device. |
| Data | Store shared records and coordinate changes. | Store downloaded data, drafts, and unfinished actions. |
| Resources | Plan server processing, database capacity, and cost. | Control memory, storage, network use, and battery use. |
| Failures | Recover from failed services and incomplete processing. | Show useful states and restore work after an interruption. |
| Updates | Deploy services while keeping them compatible. | Support app versions that remain installed on different devices. |
These are differences in focus, not strict divisions. Servers also have resource limits. Mobile apps also need to handle multiple actions at the same time.
2. Use one example: accepting a delivery order
Suppose a delivery driver uses an app to view available orders and accept one.
The app should display the list, load images, save useful information, and show whether an acceptance request is still waiting for a result.
The backend should check which orders the driver may see and whether an order is still available. If two drivers request the same order, the backend must apply the assignment rule correctly.
The API contract is the set of rules for communication between them. It defines the request fields, response fields, errors, and behavior when a request is repeated.
For example, the app needs to know whether a response to an acceptance request means “request received” or “order assigned.” Those are different outcomes.
3. Confirm what the interview includes
A mobile design question may include different amounts of the system.
| Scope | What to explain |
|---|---|
| Client only | The app's parts, local data, network calls, and recovery. Clarify the existing API's behavior. |
| Client and API | The app plus the requests, responses, and rules it needs from the server. |
| Complete system | The app, API, and relevant backend parts. |
Ask a direct question:
“Should I design only the mobile app, define the API too, or include the backend?”
If the backend already exists, you still need to ask about it. For example, how does the app load another page of orders? How does it check an acceptance after a timeout?
Spend your time on the agreed scope. Do not assume that every mobile interview excludes backend discussion.
4. Explain the same action from both sides
For order acceptance, a backend discussion may include:
- Checking the driver's identity and permission.
- Checking whether the order is available.
- Preventing conflicting assignments.
- Saving the result even if a service restarts.
- Recognizing a repeated request for the same action.
A mobile discussion follows the user's experience:
- Show saved orders if they are available. Make it clear when the list may be old.
- Request the latest list without preventing scrolling or other useful actions.
- Update the saved data and the screen.
- When the driver taps Accept, save the information needed to track that request.
- Show a waiting state while the server decides.
- Show success only when assignment is confirmed. Explain a rejection if another driver received the order.
Saving an order locally does not reserve it. The app can show a downloaded list offline, but it cannot claim that the orders are still available.
5. A timeout does not always mean failure
A timeout means the app did not receive a result within the expected time. It does not prove that the server did nothing.
Suppose the server assigns an order to the driver, but the response is lost. The app sees a timeout even though the assignment succeeded.
The app should show a message such as “Checking order status” while it finds the result. It should not immediately report failure or create a new acceptance action.
Give the action a stable operation ID and save it before sending. The server can use this ID to recognize repeated requests for the same action. This behavior is called idempotency: repeating one operation does not create an extra business result under the API's stated rules.
The app and server must agree on those rules, including how long the server remembers the ID and how the app can check the result. Creating an ID on the phone is not enough by itself.
6. Decide which data must remain after the app stops
Data kept only in memory is lost when the app's process ends. Save important data to persistent storage so the app can read it after reopening.
Not all local data has the same value:
| Data | Example | Storage rule |
|---|---|---|
| Downloaded copy, also called a cache | Restaurant image | Usually safe to remove and download again. |
| User-created work | Unsent message draft | Save it and do not remove it during ordinary cache cleanup. |
| Unfinished action | Acceptance with an unknown result | Keep its operation ID and check the server's result. |
| Sensitive information | Sign-in credential | Store only what is needed and use suitable platform protection. |
An outbox is a saved list of actions waiting to be sent. It can support offline message sending. However, not every action should run later. Accepting a delivery order several hours after the user tapped Accept may no longer match the user's intention.
Separate saving an uncertain request from scheduling a new action for future execution.
7. Separate local display data from shared decisions
The screen can read from a local database while the backend remains responsible for order assignment.
For example, the local record may say “acceptance waiting for confirmation.” That is enough to display the correct waiting state. It is not proof that the driver owns the order.
A repository is a component that coordinates access to data. It can read saved records, request updates, and save the results. The screen then reads a consistent view instead of combining unrelated copies itself. Android's offline-first guidance describes this use of local data for app reads. Android offline-first guidance
The server must still check permission on every sensitive request. A local check can help the user avoid a mistake, but a modified app could bypass it.
8. Keep the interface responsive
Users should be able to scroll and tap while the app loads data. Long database queries, image processing, or large data conversions should not block the work needed to update the screen.
Moving work away from the interface is not enough if the app starts too much work at once. Limit simultaneous downloads and processing so they do not use all available memory or processing capacity.
Images show why device resource planning matters. Suppose a decoded image uses four bytes per pixel:
- A 4,000 × 3,000 image needs about 48 MB for its pixels.
- A 400 × 300 image needs about 0.48 MB for its pixels.
These are decimal units and exclude other memory used by the app. The smaller image uses one hundredth of the pixel memory in this example.
Decoding means converting an image file into pixels that can be displayed. A small compressed file can still become a large pixel buffer in memory. Displaying it in a small box does not necessarily reduce that memory use.
Request an image size suitable for the screen and reduce its pixel dimensions during decoding when supported.
9. Limit unnecessary network and background work
Downloading fewer bytes can reduce waiting, data use, and battery use. Reuse saved images, load only a limited number of items in advance, and avoid repeated requests when nothing useful has changed.
When a temporary error occurs, wait before retrying. Increase that waiting time after repeated failures rather than sending requests continuously.
The operating system controls when background work can run. The app cannot assume it will continue running after the user leaves it. Use platform APIs appropriate for the task, save progress when needed, and make recovery work when the user returns.
For example, an interrupted upload may wait and resume later. The screen should distinguish “waiting to upload” from “upload complete.”
10. Support different installed versions
A backend update does not update every phone. Some users continue using older app versions, and some devices remain offline for a long time.
Keep APIs compatible with supported versions. Plan how saved data changes when the app is updated. Do not assume that every user receives a repair immediately.
A feature flag is a setting that selects or disables behavior already included in the app. It can help limit a faulty feature, but only if the app contains the needed control and can use an appropriate configuration. It cannot repair every crash or reach an offline device immediately.
Backend recovery also needs planning. A server deployment may be easier to control centrally, but database changes and incomplete work can still make recovery difficult.
Measure both parts of the system. Backend measurements can show request failures and processing time. Mobile measurements can show crashes, slow screens, and unfinished local work.
11. Connect requirements to decisions
A clear interview explanation can be short:
“The driver should be able to read recently loaded orders on a weak connection, so I will save them on the device. Accepting an order still requires server confirmation. If that request times out, I will keep its operation ID and check the result before showing success.”
This explains the purpose of the local database, the waiting state, and the API's recovery behavior. Use the same approach for other important decisions: state the requirement, explain the solution, and describe its limits.
Practice questions
1. The interviewer provides an existing API. What should you still ask?
<details> <summary>Show answer</summary>Ask how requests and responses work, how to load more items, what errors mean, and how to repeat or check unfinished actions safely. These rules affect the app even when you are not designing the backend.
</details>2. An order acceptance times out. Should the app immediately show “Failed”?
<details> <summary>Show answer</summary>No. The server may already have assigned the order. Keep the operation ID and check the outcome, or repeat the same operation under the API's rules. Show that the result is still being checked.
</details>3. The screen reads from a local database. Does the database decide who owns an order?
<details> <summary>Show answer</summary>No. The database supplies the screen's saved state. The backend makes the shared assignment decision. The app must distinguish a waiting request from a confirmed assignment.
</details>4. Why can a small image file use much more memory after loading?
<details> <summary>Show answer</summary>The file may be compressed. To display it, the app decodes it into pixels. The pixel dimensions and format determine the pixel buffer's size, which can be much larger than the file.
</details>Takeaway
Backend design explains shared data and decisions across users. Mobile design explains the experience and saved state on each device. A complete mobile answer connects these responsibilities through clear API rules and recovery behavior.
Reading Progress
0%
On This Page
- Compare the main responsibilities
- Use one example: accepting a delivery order
- Confirm what the interview includes
- Explain the same action from both sides
- A timeout does not always mean failure
- Decide which data must remain after the app stops
- Separate local display data from shared decisions
- Keep the interface responsive
- Limit unnecessary network and background work
- Support different installed versions
- Connect requirements to decisions
Practice questions
Takeaway