Despite how intimidating they may seem, scalability questions are actually very simple. There are no “gotchas” or tricks, and no fancy algorithms, at least not usually. However, what trips many up programmers is their belief that there is a trick to solving these problems. But there are no tricks. The questions are designed to gauge your performance in the real world, and you should approach them accordingly.
In other words, tackle the problem with the same approach you would use at work. Ask questions, engage the interviewer, and discuss tradeoffs.
If asked to design a system, such as Small URL, you would not simply say “okay” and start the design process without first asking questions. Below are the steps you should follow in an interview.
You can’t design a system if you don’t know what you’re designing. Scoping the problem is necessary in order to ensure that you’re building what the interviewer wants as it may be something that the interviewer is specifically evaluating. If you’re asked something such as “design SmallURL,” you’ll want to first understand what exactly you need to implement. Will the users be able to specify their own short URLs, or will it all be auto-generated? Will you be keeping track of any stats on the clicks? Do the URLs have a timeout?
These questions should be answered before you proceed in the design process. Make a list of the major features or use cases. For example, for SmallURL it might be:
It’s okay to make some assumptions when needed, but they should be reasonable. For example, it would not be logical to assume that your system needs to process only 100 users per day or that you have infinite memory available. However, it might be logical to design for a max of one million new URLs per day – making this assumption can allow you to calculate what proportion of data your system will need to store.
Some assumptions might take some “product sense” (which is not necessarily bad). For example, is it okay for the data to take, at max, 10 minutes to process? That depends; if it takes 10 minutes for a URL that has just been entered to work, that’s a deal-breaking issue as users generally want these URLs to be active immediately. However, if the statistics are 10 minutes out of date, that would be okay. Discuss these types of assumptions during your interview.
Get up from that chair and go to the whiteboard to draw a diagram of the major components. You might have something such as a frontend server (or a set of servers) that pulls data from the backend’s data store. You may have another set of servers that will crawl the web for specific data and process analytics. Draw an image of what this system might look like.
Go through your system from end-to-end to get an idea of your design flow. Once a user enters a new URL, what happens next?
It may help you to ignore major scalability challenges and pretend that the easy and obvious approaches will work. You’ll handle the big issues in Step 4.
When you have a basic design in mind, focus on the key issues:
What are the major challenges in the system?
For example, if you are designing SmallURL, one situation you might consider is that while some URLs will be infrequently accessed, others can suddenly spike in activity. This will happen if a URL is posted on Reddit or another popular forum, and you don’t need to constantly hit the database.
Your interviewer might provide some guidance here. If so, take this guidance and implement it.
Once the key issues are identified, it’s time to adjust your design accordingly. You might find that it involves a serious redesign or just some minor tweaking, such as employing a cache. Update your diagram on the whiteboard as your design changes.
Be open about any limitations in your design. Your interviewer will likely be aware of them, so it’s important to communicate that you are on the same page as each other.
Note that an iterative approach is typically useful, meaning that once you solve the issues from Step 3 new problems will emerge that you will want to tackle.
Your goal is not to re-design a complex system that companies have spent millions of dollars building, but rather to demonstrate that you can analyze and solve problems as they arise. Poking holes in your own design is a great way to demonstrate this skill.