0% completed
Introduction: The Mobile System Design Round
On This Page
- Understand the basic terms
- Start with what the user needs
- Explain what happens during normal use and failure
- Account for mobile device limits
- Explain why you chose a design
- Use the course's five-step method
- What this chapter covers
- How to study
Practice questions
Takeaway
A mobile system design interview asks you to explain how a mobile app should work. You discuss the app's main parts, the data it stores, how it communicates with a server, and what happens when something fails.
For example, the interviewer may ask:
“Design a messaging app that lets users read and send messages when the connection is unreliable.”
Your answer should explain more than the screens. Where is an unsent message stored? What happens if the app closes? How does the app avoid sending the same message twice?
This course helps you answer questions like these in a clear order.
1. Understand the basic terms
You will see these terms throughout the course:
| Term | Meaning |
|---|---|
| Mobile client | The app running on the user's device. In this course, “client” means software, not a customer. |
| Backend | Software running on servers. It manages shared data and rules that apply across users. |
| API | A defined way for the app and server to exchange requests and responses. |
| Local storage | Data saved on the device, such as downloaded messages or an unsent draft. |
| Requirements | The features and conditions the design must support. |
| Trade-off | A choice that improves one property but may make another worse. |
| Interview round | One interview within a hiring process. |
For example, saving more messages on the device improves offline access, but uses more storage. That is a trade-off.
2. Start with what the user needs
Before choosing tools or drawing the system, clarify the question.
For a messaging app, useful questions include:
- Do we need text messages only, or images and videos too?
- Should users be able to read old messages offline?
- Can they write a message offline and send it later?
- Should unsent messages remain after the app closes?
- Are we designing only the mobile app, or the server too?
These answers change the design. Text-only messages need less storage and transfer work than large videos. Offline sending needs a saved record of work that has not finished.
Do not assume that every product needs every feature. Agree on the important behavior first.
3. Explain what happens during normal use and failure
Consider a user who writes a message and taps Send.
A simple description is “the app calls the API.” A more complete description follows the action through these steps:
- Save the message and its unique operation ID on the device. This ID identifies one send action across repeated requests.
- Show the message as waiting to send.
- Send it to the server.
- Update the saved state when the server confirms acceptance.
- Show that confirmed state on the screen.
Now consider a failure. The server accepts the message, but its response does not reach the app. The app cannot tell from that missing response whether the message was accepted.
The design needs a way to check the result or repeat the request safely. This requires cooperation between the app and the server. Saving an ID alone does not prevent duplicate messages; the server must recognize repeated requests for that ID.
You will study these details later. For now, notice the method: explain a user action, then explain how it recovers from an interruption.
4. Account for mobile device limits
A mobile app does not control every part of its environment.
| Condition | Design question |
|---|---|
| The connection is lost | What can the user still read or change? |
| The app is closed or stopped | Which data must remain when it opens again? |
| Memory or storage is limited | Which data can be removed without losing user work? |
| Work takes a long time | Can the user still scroll and tap buttons? |
| The app is in the background | Can the work wait or resume later? |
| Users have different app versions | Will older supported versions still work with the server? |
The operating system controls when many background tasks can run. Do not assume that a task will start immediately just because the app requests it.
5. Explain why you chose a design
Different requirements can lead to different valid designs. However, a design still needs to satisfy the agreed requirements.
For example:
“Users need to read recent messages offline, so I will save those messages on the device. I will limit the saved history to control storage use. Unsent messages will be stored separately so ordinary cleanup does not remove them.”
This explanation connects a requirement to a decision and its cost.
Avoid giving only tool names. Saying “I will use a database” is not enough. Explain what it stores, why that data must be saved, and when it can be removed.
6. Use the course's five-step method
This course uses five steps to organize an answer. They are a practice method, not a rule that every company follows.
- Requirements: agree on the features and important conditions.
- API and data model: define requests, responses, and the records the app needs.
- Client architecture: divide work among the app's main parts.
- Deep dive (detailed discussion): explain the most important technical decisions.
- Failure, offline, and shipping: explain recovery, testing, and safe app updates. Here, shipping means releasing the app to users.
The course sometimes calls step 4 a “deep dive.” It means a more detailed discussion of a selected topic. You do not need to discuss every component in equal detail.
7. What this chapter covers
| Lesson | What you will learn |
|---|---|
| Mobile System Design vs Backend System Design | How to divide responsibilities between the app and server. |
| What the Round Looks Like at Each Company | How interview formats can differ and what to confirm before your interview. |
| Interview Signals and Eight Common Mistakes | How your explanation shows your reasoning and which mistakes to avoid. |
| Mid, Senior, and Staff Answers | How the scope and depth of an answer can change with role expectations. |
| The Five Step Method and the 45 Minute Budget | How to organize an answer and practice within a time limit. |
| Capstone: Grading Three Answers | How to compare three answers and identify useful improvements. |
An interview “signal” means evidence about how you think. For example, explaining how a saved message survives an app restart shows that you considered failure recovery. Companies may use different evaluation methods; there is no single report format used by all interviewers.
8. How to study
Read this chapter in order. Then study the technical chapters and attempt the app case studies.
For each case study:
- Read the question before reading the solution.
- Explain your own design aloud and draw its main parts.
- Test your design with a lost connection or an app restart.
- Read the lesson and note what you would change.
- Explain the improved design again.
Use a time limit that matches your expected interview. The course's 45-minute exercise is a practice example, not a promise about every interview's duration. Confirm the format and expected scope with your recruiter or interviewer.
If your preparation time is limited, identify the topics you understand least and practice those first. Do not choose material only from assumptions about a company or region.
Practice questions
1. Why is “the app calls an API” not a complete explanation of sending a message?
<details> <summary>Show answer</summary>It does not explain where the message is saved, what the user sees while waiting, or how the app recovers if the response is lost. A complete explanation includes these states and the server behavior needed for safe retries.
</details>2. What should you clarify before drawing the system?
<details> <summary>Show answer</summary>Clarify the main features, offline behavior, important constraints, and whether the task includes the client, the API, or the backend as well.
</details>Takeaway
A mobile system design answer explains how the app works, why its parts are needed, and what happens when normal operation is interrupted. Start with the requirements, then connect each important decision to the user's experience.
Reading Progress
0%
On This Page
- Understand the basic terms
- Start with what the user needs
- Explain what happens during normal use and failure
- Account for mobile device limits
- Explain why you chose a design
- Use the course's five-step method
- What this chapter covers
- How to study
Practice questions
Takeaway