The 4 System Design Questions You Will Encounter

I'm going to give you a formula for learning the basics of system design to help you prepare for your next interview but more importantly, to develop big picture thinking.

Writing code is great. I mean, you have to know how to write sexy, working code in order to be a developer. But at some point, that's a given. You move past junior developer and you must start thinking larger.

Unfortunately too many developers get caught up in the trap of the LeetCode grind only to discover that more leverage, respect and opportunity is at the system design level.

System design basics.

There are a few buckets of concepts you need to familiarize yourself with so you can mix and match features for the correct system:

1. Databases (SQL vs NOSQL)

2. Caching and Distributed Caching

3. Message Queues

4. CDNs

5. Database Partitioning

6. CAP Theorem

I would simply ask ChatGPT or do a quick Google search on each topic.

Here's a list of the top 4 system design questions you are likely to encounter and how to approach them:

Design a URL shortener

https://www.geeksforgeeks.org/system-design-url-shortening-service/

Design a web scraper

https://github.com/donnemartin/system-design-primer/blob/master/solutions/system_design/web_crawler/README.md

Design a News Feed

https://liuzhenglaichn.gitbook.io/system-design/news-feed/design-a-news-feed-system

Design a system to find friends near me

https://www.enjoyalgorithms.com/blog/design-yelp

Honestly, if you just memorize these 4 answers you will be prepared for the majority of system design interviews 🤫.

Memorization does !== understanding though.

Once you've gotten some familiarity with the topics above, here's how you can approach a system design interview:

Here is the pattern I follow:

1. Discuss constraints of the system

   1. How many users do we expect?

   2. Are there any SLA’s (service level agreements)?

   3. Understand the big ask: What exactly are we building and how should it work from a user’s perspective?

2. High level architecture

   1. Draw out the main components of the system (you can always add more later)

   2. Sketch out the general flow - (ex: a client makes a request which is routed to a load balancer and then distributed to a network of servers where API/s handle and store data in a database)

3. Data modeling

   1. What type of data do we expect to store

   2. For videos/pictures/images - do we want to use a CDN (hint: yes)

   3. Should we use SQL/NO-SQL (hint: safe bet is no-sql)

   4. Draw out the schema for the data

4. APIs

   1. High level overview of their functionality

   2. Are there any algorithms we should leverage (ex: can we shorten a field by using  a common hashing algo like MD5?)

5. Scaling the System

   1. CAP theorem

   2. Caching to speed requests (hint: LRU cache is safest bet)

   3. Will we need to leverage message queues/workers?

   4. Monolith API or Microservices (hint: safe bet is microservices)

   5. Can we partition the databases? How?

Once you’ve gone over a high level overview of the system and its different components, it’s time to dive into the particulars of a certain layer.

For example, for a problem that deals with geo-location, it’s probably important to dive further into the database layer and how you plan to store the location of users.

For a newsfeed, you may want to dig into the APIs that generate a newsfeed for a user.

Remember to work with the interviewer. This type of interview is more conversational than your typical coding exercise. Discuss tradeoffs and always steer the conversation towards an area you are more knowledgeable - for example as a front-end developer, you may want to focus on the APIs as opposed to database design.

Lastly, to get some real practice with system design interviews, sign up for pramp.com (FREE) and do some mock interviews with a real human.