Systems Design, Simple and Defined

Disclaimer: this is not what diagramming systems design actually looks like. Credits to Christina Morillo at Pexels

The most common topics developers and engineers are encouraged to study in preparation for interviews are data structures, algorithms, and time complexity. While these are certainly important topics to understand, I’m introducing another popular topic that developers and engineers should know and prepare for, and that’s systems design.

Systems design is defined as “the process of designing the architecture, components, and interfaces for a system so that it meets the end-user requirements” (GeeksForGeeks).

Put simply, systems design is the architecture of the entire product. In the “big picture”, so to speak, the Backend is responsible for parsing and working with data. The frontend is what users see when they use an app, and may involve rendering and displaying the data from the backend into the overall app.

Systems design, though, is the big picture. Systems design is about setting the foundations of the site; this means considering TCP/IP, storage, throughput, scalability, caching, etc. This doesn’t factor in many other tech and tech adjacent roles that can be found in a company and may be involved in the “final” product.

In larger companies, the Systems Architect or Architect Team may be responsible for the architecture or for considering systems design. At a smaller company or at a startup, this responsibility may fall upon the software engineers. At the very least, software engineers are expected to understand general systems design.

Like any interview in the technical field, the best way to do well in your systems design interview is to communicate clearly and explain your approach. One important distinction, though, is that you will not necessarily be coding.

There is no one right solution. In algorithm challenges, you can refactor your solution from brute force to more optimal and efficient solutions. Not so with systems design; Pramp says to “Think of a system design interview as a brainstorming session, driven by open-ended questions, in which you’ll be expected to competently discuss a complex system.” Since you have to consider scalability as well as other factors, you’ll now have to consider the benefits and tradeoffs of your solutions.

With this in mind, here are a few things you should review before your next systems design interview:

How is this app going to be used? Who will be using it?

This will vary depending on whether you’re using a relational database (SQL) or not (NoSQL). Consider what information you’re storing in the database, and what data types they may be.

How many users will be using this app or platform? What data might they be saving or uploading to the app? How will that be stored?

In vertical scaling, you’re increasing the size of instances (for example, going from 8GB RAM to 16GB RAM) while in horizontal scaling, you’re increasing the number of instances (for example, adding more servers or machines). What are the tradeoffs of horizontal versus vertical scaling?

Credits to GeeksForGeeks

The more I learn about various Tech and Tech Adjacent roles, the more I appreciate how much planning and building goes into an app. As Tech continues to transform industries, more and more previously unheard-of jobs will be created, which in it of itself is extremely exciting.

For those of us who have been diligently building and practicing DSAs, I highly encourage you to brush up on systems design. By writing this blog, I realized my work is a small but key piece of the whole app.

The below resources were helpful in my understanding of what systems design is and how to best prepare for an interview.

Full Stack Software Developer. Any and all opinions are my own.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store