Understanding System Design

Hello “👋”

Welcome to another week, another opportunity to become a Great Backend Engineer.

Today’s issue is brought to you by MasteringBackend, a great resource for backend engineers. We offer next-level backend engineering training and exclusive resources.

Before we get down to the business of today. Understanding System Design.

I have a special announcement: You will love this one.

Masteringbackend is launching the beta version of its platform, which allows you to learn backend engineering in one place. The platform will help you grow your backend engineering career and turn you into a great backend engineer.

Here are some of the features:

1. Roadmaps => MB Roadmap enables a structured-based learning approach for Backend engineers.

2. Project Land => MB Projects enables backend engineers to use a learn-by-building model. Build real-world backend projects without coding the frontend.

3. Backend Portfolio => Create and manage your backend portfolio with many real-world backend projects.

4. BackLand => Learn backend engineering by solving challenges in a gamifying way.

Sound interesting?

The beta version is out for testing, reviews, and feedback.

JOIN THE PLATFORM

Reply to this email if you find anything worth reporting or if there is more feedback to help us improve.

Now, back to the business of today.

I discussed “How Docker Works” in the previous edition. In this issue, I will focus on understanding System Design. In addition, I have a little story to share about a System Design interview that propelled me to start learning System Designs.

My first encounter with a System Design Interview was at a job I applied for as a backend engineer at Tiney.

Before now, I never took it seriously. I even learned it in my computer science class and got an A without real-world practice. Of course, I have built many backend systems and even engineered my projects and products from scratch (What I do at Codeprenuers).

But none of these ever prepared me for the world of System Design Interviews. It’s a different ball game and requires studying, learning, and practicing, just like Algorithm and Data Structure interviews.

Nevertheless, after failing twice in System Design interviews on different occasions and losing out on the interview process, I knew I had to take it seriously.

I studied System Design and some of its components in depth, exploring how they interact and the best possible combination of these components to result in a resilient backend system.

I have been on this journey for quite a while and want to start releasing the series on System Design.

I will explore system design fundamentals in this newsletter and why you should learn them.

Of course, we will explore each component as we progress, so you should share this newsletter with your friends.

You can also pause and do it now.

What is System Design?

System Design is a major phase of software development; it’s the process of defining the elements of a system, like architecture, components, modules, interfaces, and data for a system based on the specified requirements.

That is all there is:

Before you build any system, you draw a plan and map out all the components involved. This gives you a high-level overview of the system before you begin development.

That’s all. As simple as that. But I failed twice at very important interviews.

Looking at the image above, you can see the components that make up the TikTok backend system. For example, you can easily spot CDN (Content Delivery Network), LB(Load balancer), RDB(Relational Database), Cache, etc.

These and more are the components of the system, and your job when designing a system is to put them into good use by:

• Knowing each of these components.

• Understanding when and why you use each of them.

• Knowing where to put each component

Once you know all these, system design becomes a breeze.

Why should I learn system design?

In the last two decades, there has been a lot of advancement in large-scale web applications.

These advancements have redefined how we build software. All the popular applications and services we use daily, such as Netflix, YouTube, Facebook, Office365, and Twitter, are highly scalable distributed systems.

These systems handle billions of traffic daily, so there is a need to design the systems to tackle the amount of traffic and data with zero failure, and that’s where system design comes in.

System design requires considering everything from the infrastructure, hardware, and software to the data and how it’s stored.

Learning system design will helped me design resilient systems that are scalable, available, and efficient. Your task as a developer is to understand the basic concepts of system design and when to apply them in real-world software solutions.

However, if you want to pass your System Design Interviews and not fail them like me, consider learning System Design deeply.

You might quickly think that System Design is all about Components and where, when, and how to use them efficiently. You might not be far from the truth, but there are metrics used to measure a system's performance.

Therefore, when you design a system, you must ensure it meets some system metrics to be considered a good and measurable design.

System Design Performance Metrics

The Metrics below are used to measure the performance of a system.

1. System Reliability

2. System Availability

3. Availability Vs. Reliability

4. System Efficiency

I will only cover one in this newsletter since I’m not too fond of long newsletters(emails) and don’t want to send long ones.

System Reliability

System Reliability is the probability that a system will perform correctly during a specific time. A system is reliable when it adequately follows the defined performance specifications and requires no repair during that period.

Hardware depreciates with time, which affects a system's reliability. On the other hand, it’s difficult to measure software reliability; responses to client requests could slow down but still be accurate.

A reliable system should continue working even when the software or hardware components fail. Any failing component should be replaced immediately with a healthy one to ensure the completion of a requested task.

For instance, in a large online store like Amazon, one of the primary requirements is that a transaction should never be canceled due to the failure of the node running the transaction.

For example, if a user adds an item to a shopping cart and proceeds to payments, the system is expected not to lose it even if the transaction server fails. A reliable system should be fault tolerant, i.e., detect failures and migrate the transaction task to another redundant server for completion. A resilient system should be able to eliminate every single point of failure.

A common way to measure reliability is using Mean Time Between Failure(MTBF). MTBF is the average time between system breakdowns, which measures the performance of a system.

MTBF is calculated by dividing the total time a system runs (uptime) by the number of failures(downtimes). For instance, if a system is operational for 100 hours, it breaks down two times for 3 hours, and with an addition of 4 hours, the MTBF can be calculated as follows:

MTBF = (100hrs - 7hrs)/2 breakdowns = 93 hours/2 breakdowns = 46.5 hours

Summary

That’s all

I have discussed why I decided to start learning System Design again and why it is beneficial for you to do the same. Furthermore, I have introduced you to the basics of system design and system design performance metrics. In addition, I have listed four measurement metrics and discussed the System Reliability metric.

I will cover each in this newsletter as we do every week, so now is the best time to bookmark it and share it with your friends.

I hope this guide gives you perspective on Understanding System Design

That will be all for this one. See you on Saturday.

Don’t forget to Sign UP for the Beta version of Masteringbackend. It comes with unmatched benefits.

DON’T LEARN ALONE. SHARE THIS NEWSLETTER WITH YOUR FRIENDS

Backend Engineering Resources

1. Backend Engineering Hub

2. All Backend Books

3. Visit our Backend Store

4. Join our Community

LAST WORD 👋 

How am I doing?

I love hearing from readers, and I'm always looking for feedback. How am I doing with The Backend Weekly? Is there anything you'd like to see more or less of? Which aspects of the newsletter do you enjoy the most?

Hit reply and say hello - I'd love to hear from you!

Stay awesome,
Solomon

I moved my newsletter from Substack to Beehiiv, and it's been an amazing journey. Start yours here.