Preparing for an Android System Design Interview

Often I find many mobile developers confused about system design interviews. It starts with what type of questions are asked, what is the correct approach and most importantly how do we nail them? In this article, Let’s DISCUSS about designing a location sharing android application.

Question
“ Design an android application which shares it’s location with a server”

Understand
The first point to remember in a design interview is that the question is almost always ABSTRACT. It means unlike algorithmic interviews, you have to understand/analyze the question itself by asking follow up questions.In this case what should we know before proceeding to design the solution? Think and jot down …

Before we discuss the actual points, let me remind you that the aim of a system design interview is to gauge your skill in building a scalable system.It means your design should have optimal solution, withstand failures, and scale with users.The best part is that there is no right or wrong answer.You are free to be creative :) . Also the expectations would be reasonable. Of course, you cannot design Waze or Evernote in an hour.

Think from a mobile perspective.Mobile applications are constrained by processor, power, bandwidth, etc..So you should always keep the following points in mind while designing the solution

1. Memory Consumption
2. Battery Consumption
3. Bandwidth Consumption
4. Resilience
5. Persistance
6. Scalability (Includes Device Support as well)

Again, can you pause for a moment and think of few questions keeping the above points in mind ? Some good followup questions would be

1. What is the frequency of polling?
2. What is the desired location accuracy?
3. Any threshold b/w two consecutive locations(user may be same place)?
4. Should the location be shared even if the app is killed or in background?
5. Should we re-poll in case of failure(due to flaky network maybe)?
6. Do we need to store the location data on device?
7. Any conditions on minimum supported api level?

Once we get a clarity on these questions, we are good to go with the basic version.Lets implement.

Location Fetch :
Our main focus is to get the location of device frequently. Discuss about the various location providers in android, location api such as the Framework Location, Fused Location Provider by Play Services and compare them.If we consider the frequency of polling and accuracy to be high, it should be obvious to choose the provider as gps.

So which api should we use for location updates ? Compare between Framework API and Fused Location Provider.Using the former you have to do all the hard work of optimization whereas the latter is a smart api which does the hard work for you.You might be wondering if Fused Location Provider does everything, why do we need to consider the framework api. This is because it has dependencies on the Google PlayServices, which might not be installed on some android devices (Scalability).Remember, the location fetch strategy is crucial in battery consumption

Irrelevant, but did you ever think, how gps works and why it drains battery?

Bandwidth Utilization
For this example, device location should be shared continuously.So there is nothing much we can do to optimize bandwidth. But in general, it should be noted that batching network requests is always a preferred approach.It contributes to battery savings specially while using cellular networks.

Persistence
Since the location data needs to be stored on the device, we should discuss about various methods of persisting data on the device such as Shared Prefs, File Storage and SQLite.As the data in this case appears structured, it is obvious to use SQLite.The table structure can be something like

id latitude longitude timestamp is_posted

By the way are you aware of ROOM, an excellent library to make db management easier ?

Now, let’s be negative
Note that a design interview’s focus is not on how well your system works in a utopian world, but how it performs in a dystopian world.In algorithmic interviews, we typically start with a brute force approach and try to optimize the bottle necks to land at a better solution.This applies here as well.

Think about how our app can fail.What happens if

1. There is a network error while posting location?
2. Android detects that our cool app is draining a lion’s share of battery and decides to kill the process ?
3. The user simply moves the app to background to endlessly browse TikTok :P ?

If you are not aware, i recommend reading about Background location limits and Doze Mode for better understanding.From here onwards, we’ll discuss strategies to combat failures.

Resilience
It is important to consider resilience during the entire process rather than in the end. One way to achieve this is for every component we add, think in what ways it can fail and the recovery methods.Let’s make our app resilient

1. Location cannot be obtained : can occur because of faulty Gps receiver or the user being indoors.Try using network provider if feasible.
2. Location posting failure : Since we persist the data locally, scan for failed postings in the db and try polling in regular intervals.How frequently should we scan? A good design should discuss this as well.Think about scheduling strategies such as JobDispatchers, WorkManagers etc..
3. App in background / Doze Mode On : Most important case. Android is aggressively imposing restrictions for apps in background with every release.In our case, if the app goes into background, background location limits kicks in, location updates are received only few times in an hour !!! Also similar chaos happens during Doze and Standby mode.Think about some ways of keeping the app as a foreground process.Lets make our app a foreground process by posting a Foreground Notification.
4. Permissions : Trivial but should not to be overlooked. User is not ok granting high accuracy settings, should we fallback to network accuracy?

Scalability
Another crucial aspect of a system design is Scalability i..e, how well your system scales.Scaling should not always be thought as a Server concept, it applies to clients as well. Assume our app is liked and used by billions of people :) Now

1. How to reduce huge polls to servers which can lead to crash
2. How to change the frequency or accuracy of location post after app release
3. How to restrict uploads of failed postings at regular intervals by all users, overwhelming the server at particular times a day.

Most of the above issues can be handled with the use of remote configs.If an App update is mandatory for simple configurational change, it is not scaling well.Also it is good to know about Multiple Apks for single app.

Conclusion
Even though the article hasn’t focused much on implementation details, an old sample can be found here .I intended to provide a broad scope of an android system design interview. Now can you design a Swiggy rider app ?Thanks for reading , Feedback is always welcome