Choose a platform for building an app leveraging APIs

Clarifying Questions

This question is can be simple or complex, depending on the position you're interviewing for, your seniority, and at what stage of the interview you're at.

You'd want to get a sense of the level of depth the interviewer is expecting, and what's considered out of scope. Regardless of what direction you'd like to take it, be sure to ask if there's any expectation for scaling later. Even if the interviewer says no, be sure to spend a few minutes at the end discussing any changes you'd make to scale up significantly.

Assume, through some back and forth, that you've defined the following requirements:

• You're free to pick something you’ve built before, or choose one of your favorite apps.
• Our definition of "platform" is broad - whatever you are most comfortable with. For example, you might pick mobile app, a cloud platform, a work automation platform, etc.
• There's no need to write code – we're just looking for the high-level architecture to understand your thought process.

Solution

Step 1: Discovery

Start by first gathering any app requirements we have. Does there need to be a UI interface? Is there a specific target demographic / user base we are building for? Is anything specific we need the app to accomplish?

For simplicity, let’s pick an app everyone knows: a weather app.

Step 2: Design

The key to the design phase is to figure out what systems will be part of our architecture, how data is transferred between them, and what they will look like. We also have to make a decision on the platform and define why. This can vary based on what we find in the discovery phase, but let's assume our weather app is for millennials in the US so a mobile platform like iOS makes the most sense. If we were making a weather analytics app or something more data-oriented, we may have chosen a cloud platform to handle the computational workloads.

Typically for any sort of mobile application, there are backend and frontend services that will need to communicate with each other via API. In the case of our weather app – we will need a frontend mobile app (to house our UI), a backend service (for our UI to talk to), and perhaps a third-party weather API for our backend to query for real-time weather data.

This is a good time to also pause and diagram/whiteboard a high-level architecture:

Once we know what the relevant systems are, it's important to discuss the format in which they will communicate. For example, once a user opens the app on an iOS device, the app will need to make a /GET request to a /weather endpoint hosted by our backend. We can pass location as a parameter from the mobile app to the backend, so the API knows where we need the weather for. Then, we need to think about what the response from our backend will be to render an appropriate UI. Then, we need to think about what the response from our backend will be to render an appropriate UI. Assuming a standard JSON format, its safe to assume our backend API will respond with something like this:

It’s also good to discuss what additional functionality and endpoints we may need down the road. For example, our users might want the ability to search for weather in other cities (because they’re traveling there), the weather over a specific time period, the chance of rain/snow, etc.

What would a user in California asking for the weather in Boston the following week look like? On the UI side of the mobile application, we’d need some sort of search box for gathering the input of the desired city name. By default, we can return the weather for the next 10 days, assuming the user is likely curious about weather information in the near future. This means we need a slightly different endpoint and data structure now from what we had previously.

We can create an additional endpoint called /weatherByCity where making a /GET request will return an array of weather information for a specific location. If a user passes in “Boston” as a parameter, we can imagine our endpoint will respond with a JSON object similar to the below:

The key difference here from our previous endpoint is that the weather is now returned in an array, listing out different dates and weather information for that day. The iOS app will then need to just ingest this array response and display it accordingly in the appropriate UI view to the user. We now have our systems finalized and an example API they will use to talk to each other, let’s move on to how we would need to architect for success and scale.

Step 3: Scaling & Success Measures

Things to consider here for scale will be primarily related to how our backend handles and distributes requests for potentially millions of users. Since our user base will start in the US, we should architect for having a locally distributed backend in multiple zones (US-East, US-West, etc.). This way in case there is an issue in one region we will have the ability to fail over to another. Also, if the app is successful in the US, we should potentially plan to scale globally as well.

Ideally, we’d want a globally distributed backend to reduce latency within the mobile app (i.e. you don’t want a user in Japan needing to query a server in the US for weather). At scale, we will also need a load balancer to handle millions of concurrent requests, and distribute them across our infrastructure. Finally, it is worth mentioning caching as an option regionally when there are multiple users gathering weather for the same location – as this saves us the overall amount of data dips we need to make.

We can wrap by discussing how we can measure success outside of just counting users. Important metrics we may want to analyze are: What's the average time a user spends in the app? Are our users using the app daily or just once in a while, and are there things we can do to increase the frequency? Also, is our app more popular in certain regions than others? As our user base scales, is our application backend maintaining a low error rate and sustaining high uptime? All of these data points become important in claiming a successful app launch.