My Journey of Learning Low Level Design the Hard Way

I am starting to learn low level design and I will write my learnings and frame them as an article. Anyone who would like to learn can follow the way I did this and these articles would be more for my revision purposes only.

I will be adding all the resources in the end that I used while exploring the topics and also attach the GitHub repository link if there's any code present.

About my background

I am Abhinandan Mishra, currently working as a software engineer and have around 2.5 years of experience. I have contributed in both frontend and backend and am good at the implementation level (writing code). In my current organisation I majorly contribute in frontend projects and sometimes in backend also but I don't have enough knowledge of how to design the code structure of the system in such a way that it can be extended very easily and there is less chance of errors.

Above is my background when I am writing this first article and by the end of this article series I will again write about my background so that you can understand whether this article was good enough or not.

Just for your information whatever I will be writing in the article series will be my words only (of course will fix English using LLM).

What is low level design and why to learn?

In the system there are 4 steps that come for building a system.

Requirements
Architecture Design (HLD)
Code Design (LLD)
Implementation

Usually developers start their journey from implementation and as experience increases they move towards understanding design and architecture.

For mid level engineers LLDs are asked majorly in interviews to understand how you organise your code so that it becomes extensible, easy to understand and less error prone. However, even junior engineers are sometimes expected to know basic LLD or OOP concepts.

As experience increases engineers must be able to understand things in a broader way by thinking of how to make system more available, reliable, fault tolerant and have low latency. These are all the components of high level design.

Requirement gathering is a very ambiguous thing where you try to understand what the customer or end user needs and create a product requirement document (majorly product managers do this job in the industry).

Now we have an idea how each step is important and if you're reading this blog that means you are already good at level 4 that is implementation level and want to understand the nuances of low level design and write clean and better code.

How to solve a low level design problem?

Above question is incorrect, it should be how to create the low level design of a system or approach to create the low level design of a system.

In programming universe, whatever problems we solve today, most of those problems have already been solved somewhere either completely solved or in fragments. We just get intuitions based on our previous knowledge and then try to come up with a solution.

That's the correct way but our knowledge is limited and we do mistakes while solving a new problem and eventually we understand the better way to solve that problem. But we have limited time and we can't always afford to make those mistakes. So we can learn from mistakes done by engineers before us and we can directly inherit their learnings or patterns. Yes, in LLD these patterns are known as design patterns.

By understanding the issues and how these design patterns solved those issues our knowledge base increases and while solving a new problem this knowledge will help us not run into those issues because our intuitions are based on our knowledge.

What are design patterns?

In the past initially engineers didn't have enough knowledge so they solved some problems based on their intuitions and later point of time they faced some issues and for resolving those issues they used some patterns. These patterns are known as design patterns.

However it's not like an algorithm that you will have to follow the same steps every time and you will reach to a solution. There can be multiple designs for a single system and they can follow different design patterns but the end goal is that we don't reach the issues that we already faced earlier.

The main idea of learning these design patterns is to not make the same mistakes again and be a better engineer by increasing our knowledge base to get better intuitions while designing a system.

Design Principles

Sorry for throwing a new term without any context but yes there are certain things that a design pattern wants to achieve by following some principles.

You're not bound to design a system using a given pattern but you must always obey design principles and eventually you might end up following a design pattern at the end (not necessary that you should be aware of that design pattern).

So how people came to find these principles? Did they create principles first or patterns first?

Not exactly. After making a lot of mistakes engineers started identifying certain patterns that helped them solve problems better. Over time while studying many such solutions and patterns they started noticing similarities between good designs and from those observations some design principles were defined.

After solving a lot of problems and defining numerous patterns engineers understood the similarities between the design patterns and then they created some principles that must be followed while writing code to make sure there is very less chance of issues to happen because of code structure and to make systems easier to maintain.

How will I approach my learning now?

First I will learn design principles all of them so that I can have better understanding of design patterns.

Then I will learn some design patterns and try to solve some easy problems (not necessary to use those design patterns) and then after solving some problems learn more design patterns and solve again and do this again and again.

This would make me understand things in depth and once I have better understanding of design patterns and principles along with design and implementation then I will revisit all the solved problems and see if there can be better approach by thinking of any issue that might come in the future.

I will take time to understand things so I have a weekly target of learning 2–3 design patterns and solving a problem and in between I will write articles to update my learnings.

Resources I am using

I will add resources in every article:

https://refactoring.guru/design-patterns/what-is-pattern

https://www.youtube.com/playlist?list=PL5DyztRVgtRUqnoWYVAFC1honDiDpdKOX

ChatGPT / Gemini / Claude to understand if no other resource found

So, let's begin the journey after some meditation 🧘‍♂️