High-level Diagram for a Mobile System Design Interview supported by Chat GPT
Given the popularity of Chat GPT nowadays, I wanted to test the capabilities of Chat GPT and try something new, so I decided to use it to create a high-level diagram for a mobile app based on the problem statement “Design an Instagram Feed.”
If you haven’t already, I recommend reading my previous post here about gathering requirements for a Mobile System Design Interview. The final output from that post was the list of functional and non-functional requirements:
Functional Requirements
- Users can see an infinite list of posts (images) of the people they followed
- Users can like a post
- Users can comment on a post
Non-Functional Requirements
- Security and privacy
- Memory, network, and battery performance
- Offline mode
Out of the scope
Login screen, video support, comments list, post details, user stories
The next step in the interview is to draw a high-level design, this is not completely necessary but it is a good practice for mobile and backend System Design interviews. I asked Chat GPT about why it is good to draw a high-level design:
It is good to draw a high-level design in a mobile system design interview because it helps to clearly communicate the overall architecture and key components of the system. A well-designed diagram can provide a high-level overview of the system and show how different components fit together, which can be helpful for discussing the design with team members or stakeholders.
A high-level design can also help to identify potential issues or areas for improvement early in the design process. It can serve as a starting point for more detailed design work and provide a reference for implementing and testing the system.
Overall, a high-level design can be a useful tool for understanding and discussing the design of a mobile system in an interview or other design context.
I also utilized Chat GPT to generate a high-level design in an attempt to potentially eliminate the need for this post. Here is the result:
1. The app will have a login screen where users can enter their Instagram credentials to log in.
2. Once logged in, the app will display the user’s Instagram feed on the home screen. The feed will consist of a scrolling list of posts, with each post containing the username of the person who made the post, the user’s profile picture, the post image or video, and the caption for the post.
3. The app will also have a toolbar at the bottom of the screen with icons for navigating to other screens in the app, such as the user’s profile, the “explore” screen, and the notifications screen.
4. The user’s profile screen will display their profile picture, username, and a grid of their posts. The user will be able to edit their profile information and view their followers and following lists from this screen.
5. The explore screen will display a grid of popular posts and allow the user to search for other users or hashtags.
6. The notifications screen will display a list of notifications, such as when someone likes or comments on one of the user’s posts.
7. The app will also have a camera screen, which the user can use to take photos or videos to post to their feed.
It appears that Chat GPT is not able to draw a diagram for the mobile app. Instead, it provided a description of the app’s behavior and did not mention specific software components. So for the sake of the mobile engineers, it looks like Chat GPT is yet not able to do this part of our work.
For this and the next parts of the interview, you have to think as a Software Architect explaining the design to a Junior Engineer. I used Lucidchart to draw the diagram. This is a high-level diagram for the problem:
While you are drawing components you will need to explain the responsibility of each component and how it interacts with the other ones.
Backend: this is an abstraction of the whole server-side structure.
CDN: used to store and deliver static content to the client. This component will store only images for this case.
Networking: responsible for communication with the backend and propagating the responses to the repository.
Data storage: persist the data inside the smartphone. This will be the single source of truth for the system (See approach 2 in the next section).
Repository: is a middleman between networking and data storage components. Has the responsibility of deciding when doing a network request or when using the stored data, and also it propagates the responses to the Post Feed.
Post Feed: contains all the UI-related sub-components to display an infinite list of posts, like a post and comment on a post. This component uses the repository to get the data used to populate the post list, like a comment, and comment on a post.
Image Loader: usually represented as a third-party app (Glide, Picasso, SDWebImage). It has the responsibility of downloading and caching the images from the CDN and loading the image in a target.
A usual discussion in this part is how the offline mode will work for this case. To solve this question you will have to think about how the networking, data storage, and repository interact with each other.
I asked Chat GPT “What are good strategies for offline mode for mobile apps”:
There are several strategies that can be used to design an effective offline mode for a mobile app:
Cache frequently used data: Store a copy of frequently used data, such as the user’s feed or profile information, locally on the device so that it is available when the device is offline.
Use background synchronization: Use background tasks or push notifications to periodically sync data with the server when the device is online. This can help keep the locally cached data up to date.
Queue actions for later: Allow the user to perform actions, such as liking a post or making a comment, while offline. Queue these actions and sync them with the server when the device is back online.
Use offline fallbacks: If certain features of the app are not available offline, provide offline fallbacks or alternatives. For example, the app could display a list of the user’s saved articles when offline, rather than the full feed.
Notify the user: Let the user know when the app is in offline mode and which features are available. Provide clear instructions for how to get back online and sync their data.
Those strategies totally make sense! amazing! From my personal knowledge, there are 3 general approaches:
Approach 1 — Network as a single source of truth: this applies to apps not supporting offline mode. You don’t need a data storage component as the data comes from the network. This is not an option for our use case as Offline mode is part of the non-functional requirements but I wanted to bring it here.
- Pros: simpler implementation, less code to write, doesn’t need to think of ways of synchronizing with the server, better for privacy and security as you are not saving sensitive information of the users.
- Cons: no offline mode, frequent calls to the servers, and doing a lot of network requests can cause draining of the battery.
Approach 2 — Stored data as a single source of truth: assume the data storage has the most recent data and the repository always takes the data from there. If you will follow this approach, you have to think of ways to synchronize the remote and local data.
- Pros: less frequent calls to the server, the better offline mode possible in terms of UX
- Cons: a more complex approach in terms of coding, the user can see outdated data in case of failures in sync and need to think in encryption to store sensitive data.
Approach 3 — Network as P1 and stored data as P2: another option is always trying to get data from the network, storing it in the data source, and only using the stored data as a backup.
- Pros: simpler compared to approach 2, no sync mechanism with the server needed, the user will be able to use the app with no internet connection, and the user will always see the most recent data.
- Cons: unnecessary network calls to the server, partial offline mode functionality, privacy issues as data is downloaded.
For this example, I will choose approach 2. As this app is intended to be used by billions of people and the feed feature is expected to be the top 1 of our app, then the system must be designed to be as smooth as possible and bring the better possible experience to the users.
Discuss the decisions taken with the interviewer, read your initial requirements again, check that the high-level design has everything you need to cover the requirements, and move forward to the final step of the Interview the “Deep dive discussion”.
Final thoughts
Chat GPT can be very useful in generating general ideas and clarifying concepts. However, it is not capable of completing all tasks on its own, such as creating a high-level design or choosing the appropriate components for an application.
On another side, in order to succeed in a Mobile System Design Interview, it is important to consider the overall components of the app and how they address the initial requirements. It is not necessary to focus on implementation details or specific architectural design patterns at this stage.
Hope you enjoyed reading this!
References
