The System Design Interview For Mobile Developers 2022

Background

Having worked as a mobile developer for the majority of my tech career and having just finished up a round of on-site interviews with tech companies including Google, Microsoft, and Facebook I noticed that there is not a lot of information around how to prepare for a System Design Interview as a mobile developer. If you search for system design interviews on Google or YouTube you will find great resources and examples of how to approach this interview from a web development point of view that requires you to think in terms of scalable backend systems. These concerns shouldn’t be ignored by mobile developers, but unfortunately many of these resources ignore some of the unique concerns around system design that mobile developers should really be focused on.

What To Expect

Depending on the company you are interviewing with and their current expertise with mobile, your system design interview may look very different. This is why it’s very important to not only be familiar with mobile specific system design topics, but to also be prepared to delve into backend topics like the advantages and disadvantages of SQL / NoSQL databases. For the most part I found that larger tech companies that have a good number of mobile developers assisting with interviews are very focused on mobile specific problems and they will dig into things like UI wire frames for an application, threading concerns, data and battery usage concerns and even high level data flow of model objects through an application. If a company has less of a mobile culture in place already then you may be answering questions around server side components, database choices, file / block storage options and when to transfer to long term storage, server side scaling and load balancing traffic concerns… Basically, if you’re interviewing at a company where mobile development and the unique concerns associate with mobile development are not well understood then you may be answering questions that are well known to the interviewer so you need to be at least conversant in some of these non-mobile specific topics.

Components Of A System Design Interview

Regardless of the kind of mobile system design interview you happen to receive I recommend starting with this acronym: RADCHEB

• Requirements Clarification
• API
• Data Model
• Calculate Usage Estimations
• High Level Design
• Exhaustive Design
• Bottle Necks

Requirements Clarification

At the very beginning of this interview you should be given a set of requirements for the system you are being asked to design. For example:

Design a pet store's app. 
The app should allow customers to browse available pets. 
The app should maintain an inventory of available pets.
The app should allow a customer to place an order for a pet.

This is the best time for you to clarify any questions you might have about the system you are being asked to design, and you should have many questions here! Different interviewers are going to be looking for you to delve into different aspects of the design or to at hear your thoughts about these components. This is also an opportunity to make sure you don’t build the wrong thing. This mirrors the communication you may have with a product owner on the job. Here you should be showcasing your ability to think deeply about the implementation and the parts of the system you will need to build to support the requirements being asked for.

Given the above requirements there are a few questions I would have before jumping into the next level of our RADCHEB acronym.

“Who are the actors in our system?“
Looking at our requirements so far, we clearly have a customer in our system, but who is the pet store owner? Or maybe there is no owner and this is a craigslist style marketplace where customers facilitate transactions amongst themselves? In that case the actors in our system might only be Customer and an Administrator. Otherwise we would have Customer, Store Owner and Administrator actor types.

“Does the user need to be logged in to view available pets?”
This could be an important question because it affects the API design and the user’s flow through the application. If the user needs to sign in before he is able to view available pets then the API should probably require a user authentication token and we would need to think through the design of a login experience for the user in addition to the above requirements.

“Who can post new pets to the Pet Store?”
Building off of our previous questions around actor types and authentication we can dig a little deeper on some of the functionality of the store. This will help us when we get to defining the API and Data Models so that we can understand what capabilities are available to which user.

“How should the inventory of pets be pets be sorted”
Here you should really be driving the answer to this question. You could start by listing possible sorting and filtering capabilities the system might include. The interviewer should let you know whether that is something he is interested in digging into with you or not. At any point you shouldn’t be surprised if the answer to the question is “it doesn’t matter”, if that’s the response then you should be prepared to quickly move on to other concerns. Remember, you are trying to zero in on the information the interviewer wants to see if you know. Your goal is not to expand the scope unnecessarily and elaborating on a topic that the interviewer doesn’t want to get into won’t earn you any more points in the interview even if you feel like it’s important.
If the interviewer does see this as something to expand on then this will be an important aspect of the system design to explore because in order to filter or sort on data it will need to be a part of the data models you define.

Data Model

(Even though API comes before Data Model in the Acronym RADCHEB I usually start with the Data Model first because you’ll often want to reference different data models in the API outline)

How you define the API and Data Model is an important decision because you can use this step to demonstrate a couple of important concepts. As a mobile developer, defining an interface between the client and the server is an important part of the system design process to be involved in. This is something that experienced teams do prior to building a new application or features and your approach here can help to differentiate you from other developers who might not have thought through this step. Which method you use to communicate the data model is up to you and since you can’t foresee what kind of questions you might be asked about the data model you choose, you should definitely pick the one which you are the most familiar with.

Entity Relationship Diagram

An ERD diagram is a standard way of expressing models and relationships among the models in a system. Since this is a standardized way of expressing this information it’s a great choice for use in a System Design Interview even for a mobile developer.

Open API Specification (Swagger Spec)

definitions:
  Order:
    type: "object"
    properties:
      id:
        type: "integer"
        format: "int64"
      petId:
        type: "integer"
        format: "int64"
      quantity:
        type: "integer"
        format: "int32"
      shipDate:
        type: "string"
        format: "date-time"
      status:
        type: "string"
        description: "Order Status"
        enum:
        - "placed"
        - "approved"
        - "delivered"
      complete:
        type: "boolean"
        default: false
  User:
      etc...
  Pet:
      etc...

The Open API specification is a standardized way of representing Data Models that can be shared between the client and the server. Using the Open API Specification to describe system models during a System Design Interview will most likely mirror the process for working with a backend developer on the job most closely, but it is a lesser known standard than the ERD diagram. One advantage to the Open API Specification is that it includes a standard framework for representing API requests and responses in addition to models and relationships between models which is the specialty of the ERD. I wouldn’t recommend trying to match the syntax of this specification in your interview, but you it’s a good standard framework for expressing API requests, responses and data models and explaining you’d use a standard specification (whether it’s: OpenAPI spec, Proto Buffs, or a GraphQL spec).

JSON

// Pet Model
{
   "id": 1,
   "category": {
     "id": 0,
     "name": "DOGS"
   },
   "name": "doggie",
   "photoUrls": [  "mydogimage.jpg" ],
   "status": "available"
 }

If you’re not familiar with either of the above methods of describing system models then just writing out an example JSON object is a good alternative. An example JSON model is good, but it’s missing important meta data about your system models that you would definitely want to know before building a real system and it’s possible your interviewer will want you to provide this information. Trying to fit type or relationship information into a JSON model is probably not something you want to be exploring during an interview so if you’re going to go this route definitely think about how you might represent this supplemental information on a white board if asked.

API

This is your chance to describe the interface between the backend application and the mobile client. Here we’ll look at some of the specific actions that we’ve been asked to support in our application. Generally this is expressed via a REST API, however if you’re familiar with other alternatives than this would be a good place to discuss the tradeoffs between REST, GraphQL, gRPC or even… SOAP. Since most interviewers will be happy with a discussion centering around RESTful API design I’ll focus on this here.

The app should allow customers to browse available pets.

In order to support this feature in our app we’re going to need a way to request all the available pets on the marketplace. Our basic request might look something like this:
GET /pet/findByStatus
This is a good start, but there is a lot of information missing here. Can we pass any parameters to this endpoint that might allow us to modify the response we receive? Can we filter the response by category or availability? Can we modify the number of responses we receive? What does the response from this API actually look like? Do we need to be authenticated to use this API? What are the possible error states or responses?

The Open API Specification once again comes to the rescue here in that it provides a structured way to answer these questions. We could modify the above API definition to provide a bit more detail about the request.

/pet/findByStatus:
    get:
      parameters:
      - name: "status"
        in: "query"
        type: "array"
        items:
          type: "string"
          enum:
          - "available"
          - "pending"
          - "sold"
          default: "available"
      responses:
        200:
          description: "successful operation"
          schema:
            type: "array"
            items:
              $ref: "#/definitions/Pet"
        400:
          description: "Invalid status value"
      security:
      - petstore_auth:
        - "read:pets"

Once again, I wouldn’t recommend trying to match this syntax during a white board interview, but again the Open API Specification provides a nice framework for the kind of information an interviewer is going to be looking for you to define around this API: What are the REST semantics of the request? What are the parameters of the request? What does the response look like? What possible errors could be returned by this API? What is the secure access scope of this API? Feel free to communicate this information in whatever way is most comfortable for you.

Calculate Usage Estimations

This is one area where system design interviews can vary wildly. Depending on the background of your interviewer you may be expected to focus on some usage concerns for the backend system OR usage concerns on the mobile client. These are entirely separate approaches to a very complicated question, but I hope that this overview will give you a fighting chance during whichever version of the interview you might find yourself in. For more detailed explanations please see these YouTube videos:
Jackson Gabbard — Intro to Architecture and Systems Design Interviews
Success In Tech — How to design Twitter? Interview question at Facebook, Google, Microsoft

Backend Focused

You might want to start here with another Acronym, because you’ll have a few different things to consider here. They might not all be relevant depending on the system you’re being asked to design, but it wouldn’t hurt to have them memorized so you can write them down on the white board and signal to the interviewer that you’re at least thinking about these possible constraints. Forty-five minutes to an hour is a short amount of time to design a real software system so your goal should be to cover as much breadth as possible while diving down into the most relevant areas, the areas your interviewer guides you towards or preferably the areas where you can showcase the deepest amount of expertise.

• Traffic
• Storage
• Bandwidth
• Memory

Traffic

Generally a good place to start with usage estimations is to agree on the number of users with the interviewer (or simply throw out a number that seems reasonable to you and run with it). All additional calculations will flow from the estimated number of users in a system.

Let’s assume our Pet Store has 1 million visitors a day. We can also assume that requests for viewing available pets are going to vastly outnumber users who are placing orders for a pet or creating a new advertisement for a pet that is for sale. We can estimate that every visitor browses an average of two pages of pets per day, but only one out of a thousand visitors posts a new pet for sale.

1 million (visitors per day) * 2 (pages of pets) * 10 (pets per page) = 20,000,000 Pet Ad read requests /day
1 million (visitors per day) * 1/1000 (1 out of a thousand visitors posts a new pet) = 1,000 New Pet Ad write requests /day

Storage

Now that we have an estimate for the number of new pet ads we’ll see added per day we can estimate the amount of storage we’d need. The most significant storage concern for each new pet advertisement is going to be the picture associated with that pet (for now we’ll also assume there is only one picture per pet).

356 (days /year) * 1000 (pictures uploaded /day) * 500 kb (average picture size) = 178 GB /year of storage required

Bandwidth

Bandwidth requirements can be broken down by read and write requests. We’ve already estimated that we can expect to need to retrieve 20,000,000 pet ads per day. From there we can estimate the number of megabytes per second we’d need our servers or cache systems to be able to support.

20,000,000 Pet Ad Requests /day * 500 kb (avg ad size) = 10 tb
10 Terabytes / (24 hrs * 60 mins * 60 secs) = 116 mb/second

We’ll need substantially less bandwidth for writes.

1,000 Pet Ad Writes /day * 500kb (avg ad size) = 500 mb
500 Megabytes / (24 hrs * 60 mins * 60 secs) = 6 kb/second

Memory

Since the number of reads far outweigh the number of writes we can see a substantial improvement in response times by caching the most frequently accessed pet ads. If we follow the 80:20 rule and cache the 20% most frequently accessed pet ads we’ll see an improvement in response times without needing to cache 100% of pet ads.

20,000,000 (Pet Ad Requests /day) * 20% * 500kb = 2 Terabytes

Mobile Focused

While usage estimations for backend systems generally focus on the amount of servers, storage and cache capacity necessary to fulfill usage requirements among all users of a system, the mobile focus for usage estimations revolves more around ensuring optimization of usage from the client perspective. The usage factors you might want to consider discussing during this portion of the interview include: Battery usage and Network data usage.

The main drivers of battery usage are CPU, Networking, Location Tracking and Graphics rendering. Depending on the system you’re being asked to design you’ll want to think about the impact these individual components will have on battery usage. In our Pet Store example our main concern around battery usage would be the network requests made by our application to fetch pets for display or to post new pet ads. Analytics payload requests should also be considered in this calculation.

We’ve previously estimated that users might browse 20 ads per day.

20 ads * 500kb = 10 mb

An estimated ten megabytes of downloads a day is a pretty large amount of data for a single application and it’s worth considering options for minimizing this transfer. One unique consideration of mobile applications is their reliance on mobile data networks that may consume a finite amount of data available from a data plan. Because of this it’s especially necessary that app developers take the usage of data seriously because it may incur a real financial cost on the user.

Local caching is a good option for starting to eliminate the possibility of duplicate requests. There are a few options to consider with local caching as well. The local cache for the pet store application could expire when the application is killed or we could persist our local cache of ads and reload them when the application is launched again. In the persistent storage case the application would only need to load new ads from the network. Depending on the use case for our application a persistent storage for images may or may not be useful. For an application like twitter where the user is always looking for news feed items that are updated by the millions every second a persistent store of a previous session’s items are less important then a Pet Store’s most popular ads for your location which would most likely not change very often.

Local caching means fewer network requests which in turn means less battery usage. Even though we’re reducing the amount of data that needs to be transferred and therefore reducing battery usage every single request (no matter how brief) has an amount of system overhead associated with initializing all of the parts of the hardware on the device that are required to make the network request.

Because of the overhead required for each network request it’s best to package requests together whenever possible. When fetching components for display to the user there is little to no leeway when it comes to putting off these requests for later batching. Application analytics are a prime candidate for request batching.

High Level Design

The high level design is an opportunity to quickly sketch out how the different parts of the system you’ve designed so far would interact. This is your opportunity to point out major pieces of infrastructure such as the different types of storage options for your backend system. Does the system you’re designing require some sort of block or file storage or is a database sufficient. At this point you might be asked to dive into the type of Block Storage or Database you think would be the best fit for this type of system. If the interviewer is interested in going this deep into backend system design then you can probably expect questions about the advantages and disadvantages of SQL or NoSQL databases as well.

Exhaustive Design

System design interviews aren’t any longer then your normal interview so you probably won’t have enough time in your interview to get to this level, but you probably want to at least discuss some of the design decisions you might take into account when you start taking a more exhaustive look at your system’s design. For example, in the exhaustive design below instead of just showing a single database, we’ve expanded to a bit more detail. We’ve now expanded the example to include a write database as well as multiple read and backup databases. Since we’d previously made the assumption that our reads to writes ratio would be around 100:1 this makes sense for our system. Additionally we’ve added some caching system (no need to be specific here unless asked) that will handle caching requests in order to hopefully additionally speed up read requests.

Bottle Necks

There are a few potential bottlenecks for our system if this Pet Store reaches a massive audience. The first bottleneck being that a single server can only handle so many requests by itself so if possible it would be good to break out our different services (Fetch Ad and Post Ad) into multiple servers so we can scale the services individually.
Another bottleneck in the system we’ve described so far might end up being the way our ads are stored across multiple databases. If we store ads based on userID then it would be simple to find the database associated with a particular user and find all of the user’s videos. However, if a particular user has very popular ads then a single database may receive significantly more traffic than others. Another way to distribute ads across databases might be to store them based on the adID which would make looking up an individual user’s ads slower, but it would distribute the ads across databases more evenly. (For more examples here simply search for “Sharding Strategies”)

Conclusion

Best of luck on your Mobile System Design Interview! Let me know if you found this useful or if you have any suggestions for improvement.