How to approach any system design interview problem?

Despite how intimidating they seem, scalability questions can be among the easiest questions. There are no “gotchas”, no tricks, and no fancy algorithms - at least not usually. What trips up many people is that they believe there’s something “magic” to these problems - some hidden bit of knowledge.

It’s not like that. These questions are simply designed to see how you would perform in the real world. If you were asked by your manager to design some system, what would you do?

That’s why you should approach it just like this. Tackle the problem by doing it just like you would at work. Ask questions. Engage the interviewer. Discuss the tradeoffs.

Design: Step-By-Step

If your manager asked you to design a system such as Tiny URL, you probably wouldn’t just say, “Okay”, then lock yourself in your office to design it by yourself. You would probably have a lot more questions before you do it. This is the way you should handle it in an interview.

Step 1: Scope the Problem

You can’t design a system if you don’t know what you’re designing. Scoping the problem is important because you want to ensure that you’re building what the interviewer wants and because this might be something that the interviewer is specifically evaluating. If you’re asked something such as “Design TinyURL”, you’ll want to 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 need to keep track of any stats on the clicks? Should the URLs stay alive forever, or do they have a timeout?

These are questions that must be answered before going further Make a list here as well of the major features or use cases. For example, for TinyURL, it might be:

• Shortening a URL to a Tiny URL
• Analytics for a URL
• Reteving the URL associated with a Tiny URL
• User accounts and link management.

Step 2: Make Reasonable Assumptions

It’s okay to make some assumptions (when necessary), but they should be reasonable. For example, it would not be reasonable to assume that your system only needs to process 100 users per day or to assume that you have infinite memory available. However, it might be reasonable to design for a max of one million new URLs per day. Making this assumption can help you calculate how much data your system might need to store.

Some assumptions might take some “product sense” ( which is not a bad thing). For example, is it okay for the data to be sold by a max of ten minutes? That all depends. If it takes 10 minutes for a just-entered URL to work, that’s a deal-breaking issue. The users usually want these URLs to be active immediately. However, if the statistics are ten minutes out of date, that might be okay. Talk to your interviewer about these sorts of assumptions

Step 3: Draw the Major Components

Get up out of that chair and go to the whiteboard. Draw a diagram of the major components. You might have something like a frontend server (or a set of servers) that pulls data from the backend’s data store. You might have another set of servers that crawl the internet for some data, and another set that process analytics. Draw a picture of what this system might look like.

Walkthrough your system from end-to-end to provide a flow. A user enters a new URL. Then what? It may help here to ignore major scalability challenges and just pretend that the simple, obvious approaches will be okay. You’ll handle the big issues in Step 4.

Step 4: Identify the Key Issues

Once you have a basic design in mind, focus on the key issues. What will be the bottlenecks or major challenges in the system? For example, if you were designing TinyURL, one situation you might consider is that while some URLs will be infrequently accessed, others can suddenly peak. This might happen if a URL is posted on Reddit or another popular forum. You don’t necessarily want to constantly hit the database.

Your interviewer might provide some guidance here If so, take this guidance and use it.

Step 5: Redesign for the Key Issues

Once you have identified the key issues, it’s time to adjust your design for it. You might find that it involves a major redesign of just some minor tweaking (like using a cache). Stay up at the whiteboard here and update your diagram 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’re aware of them, too.

Note that an iterative approach is typically useful. That is, once you have solved the problems from Step 3, new problems have emerged, and you must tackle those as well.

Your goal is not to re-architect a complex system that companies have spent millions of dollars building, but rather to demonstrate that you can analyze and solve problems. Poking holes in your own solution is a fantastic way to demonstrate this.