Separating myths from best practices is a major challenge when designing production-ready systems. Let's face it:
Learning something new (in this case, system design) comes with the danger of following bad advice. This blog will help you identify myths about system design and its fundamental principles. After reading this, you can make informed decisions on what you should and shouldn't do for your software system.
Let's bust 13 myths related to system design:
Myth #1 - System design is a linear process
The truth is that system design can be a very complex process that involves many different steps and phases (insert lyrics,” Life goes on, and on, and on, and on, and on, and On, and on, and on”). However, the goal of system design is always the same - to create a system that will achieve its intended purpose. Some design steps in the process are at your discretion. If you are designing a system that is intended to be simple, you may not need to go through the capacity estimation, security guarantees, etc...
However, if you are building a system that is open to many users, scalable, and extensible, you will find yourself going through multiple iterations and reviews while designing the required system. The different phases of a system design are problem definition, service definition, API definition, and data definition. These are interconnected pieces of a puzzle, often needing multiple iterations to find the best solution.
Myth #2 - All requirements can be known upfront
If someone tells you that they know your system's requirements before you build it, run! As much as you may want to, knowing a complex system's requirements is impossible before you build it. Many features in the system design process are discovered along the way. If you need to backtrack or sidestep some requirements as user expectations change, that's fine.
Researching, interviews, focus groups, surveys, and user testing reduce wasted efforts. You may even need to go through these steps more than once. This skill also helps when dealing with system design interviews.
Myth #3 - The more features, the better
The opposite is true - too many features can hinder a system's success. When designing a system, focus on the core features of the system. Including too many features will complicate the system architecture. Not all features need to be included in the system - some may be added later as the system evolves. Remember, slow and steady wins the race!!
The key is to focus on the essential features that will make the system successful.
Myth #4 - The user is always right
Users are always right - until they are not. Yes, the user is the one who will be using the system the most, therefore their needs must be taken into account when designing the system. But you should also design the system so that it is easy to use for future users.
As Morgan Freeman says in Bruce Almighty: "Since when do people know what they really want?"
The user is the best person to know what they need and how they use the system at the moment. The user may be unable to understand the system's internals or its intended purpose. Make your system scalable based on your current and future needs.
Myth #5 - Perfection is the goal
The goal of system design is not to create a perfect system but rather to create a successful system. A successful system meets the users' needs. Over-engineering is a real problem. Trying to make a temporary email client super scalable is a waste of teamwork and a waste of other opportunities.
No system is perfect. Keep it simple!
Myth #6 - Architects must be know-it-alls
Contrary to how we look, designers do not work in isolation. We often work with other designers and developers to create a successful system (hence the fist fights). This is a team effort. Each member of the team brings a unique perspective to the table. The system designers need to understand each stakeholder's needs and put them into action.
Myth #7 - The design is done when the coding is finished
The design of a system continues even after the coding is finished. The design is revisited as the system evolves. The initial goal is to create a flexible system that can be easily changed as the needs of the users change. It is also important to remember that the system will need to be maintained and updated as new features are added. Take Swiggy: it started as a food delivery app that now delivers daily groceries too!
Who knows, they may even bring in an instant window shopping feature. I am waiting for that with bathed breath 😛.
This is why it is important to test the system for extensibility before it is released to the public. Otherwise, the new design may not adapt quickly and be abandoned.
Myth #8 - Documentation is optional
Documentation is optional for small features with few users. For large systems, it can make or break the business.
Migrating to a new system, onboarding new engineers and debugging across teams is very difficult as it is. With poor documentation, these challenges become near impossible. Having well-written and accurate documentation also allow users to find the information they need to complete their tasks quickly. If the history of changes made and the progress of the system are documented, the development team can find problems and correct them faster. Developers can also find design mistakes to learn from and avoid them in the future.
Myth #9 - Designers need not code systems
Most designers prove their design by coding the proof of concept themselves. For smaller projects, the designer and engineer are the same people!
Hence, system designers eventually need to know implementation details and the technical challenges faced when building their systems. Else, there will be a mismatch in expectations and communication gaps.
Myth #10 - Design is about reading research papers
It is only possible to build a system that meets all requirements by understanding it in depth. Using established design patterns or taking inspiration from other systems is fine. But at the end of the day, you are building this system for your users.
Testing, logging, and simplicity are more important than fancy algorithms when designing systems.
Myth #11 - System Design is only for complex systems
This is a self-fulfilling prophecy since most poorly architected systems tend to stay small. It's also a risky bet since you don't feel worried about problems until they become too big! By the time you move to refactor (or likely hack through) a solution, it may be too late.
Think about UPI or WebRTC. These solutions have been used billions of times, and they work because their designs are well thought out. A relatively small investment for massive future returns.
Myth #12 - Not all developers need to learn System Design
It is often said that not all developers need to learn system design. I disagree.
A state of curiosity and an explorer mindset help us identify patterns and pick solutions from different engineering principles. This isn't about learning a cool new framework, it is about knowing how a part of engineering works. As you take up more responsibility, you need to upgrade yourself constantly. One of the building blocks of an engineer's career is how well they work with people and how well they design solutions.
Myth #13 - You need some experience before learning System Design
Another big misconception is that you should wait until you have been hired as a system designer before learning it. This is not true. Every software engineer needs to know how systems work. It is necessary to have a 360-degree view of what you are working with. I strongly suggest you start with system design even before you are hired. You will know the stories and theory in-depth, which does wonders in practice. We offer structured content, challenging quizzes and detailed PDFs in our system design course.
———————————————————————————————————
Explorers! Check out more on our YouTube Channel or our video course at InterviewReady.
So what is stopping you from getting InterviewReady?
