System Design Introduction - LLD & HLD

System design is the process of designing the architecture and components of a software system to meet specific business requirements.

• Involves translating user requirements into a detailed blueprint that guides the implementation phase.
• The goal is to create a well-organized and efficient structure that meets the intended purpose while considering factors like scalability, maintainability, and performance.

System Design in SDLC

• In SDLC (Software development Life Cycle), without the designing phase, one cannot jump to the implementation or the testing part.
• System Design is a vital step and also provides the backbone to handle exceptional scenarios because it represents the business logic of the software.

System Design can be divided into two complementary parts

High-Level Design (HLD)

It lays out the overall architecture of the system — how major components interact, what services or modules will exist, and how data flows among them.

• Gives you the big picture: how the system fits together, its core structure, and major decisions.
• Done by architects, stakeholders and managers

Prerequisite Technical Knowledge for HLD

• Basic Coding Skills (Data Structures and Algorithms)
• Compared to Low Level Design, High Level Design is typically done by more senior people who have hands-on experience on software projects.
• Knowing the roles of components like databases (SQL and NoSQL), caches (Redis, Memcached, CDNs), and APIs.
• Low Level Design (Object Oriented Programming and Design Patterns)
• In-depth understanding of Functional Requirements (What the system must do e.g., user registration, streaming) and Non-Functional Requirements (How the system should perform—scalability, latency, availability, security, etc)
• Networking and Security Fundamentals like DNS, protocols (TCP/UDP, HTTP, WebSockets), OAuth, JWT, TLS/SSL, rate-limiting, API security, and basic DDOS protection
• Message queues and streaming tools like Kafka or RabbitMQ.
• Knowledge of Microservices vs. Monoliths (When to split services and how to manage dependencies), fault tolerance, fallback strategies, redundancy, Load Balancer Types & Algorithms.
• Observability tools like Prometheus, Grafana, ELK Stack (Elasticsearch, Logstash, Kibana) and Alerting systems (e.g., PagerDuty)

Topics Covered in HLD:

• System architecture overview: Defines the major components, modules, and how they interact (e.g., services, queues, databases)
• Data flow and component interaction: Illustrates how data moves between modules, along with key integrations and interfaces
• Technology stack and infrastructure: High-level decisions on frameworks, platforms, hardware, databases, and hosting setups
• Module responsibilities: Describes what each module does and how they relate to one another
• Performance & trade-offs: Includes design trade-offs, performance considerations, scalability, security, cost, and other non-functional factors
• Artifacts: Commonly includes architecture diagrams, component and deployment diagrams, data flow diagrams, and possibly ER/DB schematic overviews.

Real World Examples of HLD Decisions

• Netflix transitioned their entire backend from a monolith to microservices (starting with encoding and UI services), completing the migration by 2011 to scale rapidly during high-load events like holiday seasons.
• Uber adopted an event-driven architecture where ride requests, location updates, and fare changes emit events that trigger real-time systems like driver matching, billing, and dynamic pricing.
• Twitter deployed a load-balanced architecture with caching of trending topics and tweets to quickly serve millions of users and handle real-time data flows efficiently.

Low-Level Design (LLD)

It covers how each part works & is implemented internally

• Gives developers a clear, actionable blueprint to build each component.
• Once a High Level Design is built by stakeholders, it is the job of senior developers and designers to create a low level design.

Prerequisites / What You Should Know First:

• Basic Coding Skills (Data Structures and Algorithms)
• Strong grasp of OOP concepts (Encapsulation, inheritance, polymorphism & abstraction)

Topics Covered:

• Component/module breakdown: Detailed internal logic for each module—with class responsibilities, methods, attributes, interactions
• Database schema & structure: Designing tables, keys, indexes, relationships with SQL/NoSQL refinements
• API & interface definitions: Precise request/response formats, error codes, methods, endpoints, and internal interfacing
• Error handling & validation logic: Define how each module manages invalid inputs, failures, edge cases, and logging
• Design patterns & SOLID: Implement design patterns and solid principles to ensure clean, extensible, maintainable code
• UML and pseudocode artifacts: Class diagrams, sequence diagrams, pseudocode or flowcharts to clarify logic paths and method calls

Steps for getting started with System Design

Here are some steps to get started with system design:

1. Understand the requirements:
   • Before you begin designing the system, you need to understand the requirements. This involves talking to stakeholders and users, reviewing existing documentation, and analyzing the business processes that the system will support.
2. Define the system architecture:
   • Once you have a clear understanding of the requirements, you can begin defining the system architecture. This involves identifying the major components of the system and the interfaces between them.
3. Choose the technology stack:
   • Based on the requirements and the system architecture, you can select the technology stack. This includes choosing the programming language, database, frameworks, and libraries that will be used to implement the system.
4. Design the modules:
   • Next, you need to design the modules that will make up the system. This involves defining the functions that each module will perform and the data that it will manipulate.
5. Plan for scalability:
   • As you design the system, you need to consider how it will scale. This involves identifying potential bottlenecks and designing the system to handle increased loads.
6. Consider security and privacy:
   • Security and privacy should be a key consideration in system design. This involves identifying potential security threats and designing the system to mitigate them.
7. Test and validate:
   • Once the system design is complete, you need to test and validate it. This involves creating test cases and scenarios that simulate real-world usage and verifying that the system meets the requirements.

Overall, system design is a complex process that requires careful planning and attention to detail. By following these steps, you can create a system design that meets the needs of your users and your business.

Tips and Tricks to solve System Design Problem

• When you are given a System Design Problem, you should approach it in a planned manner.
• Initially, the Problem may look huge, and one can easily get confused about how to start solving it.
• And moreover, there is no fixed solution while you are designing a system.
• There is more than one way to reach the Solution.

So let’s discuss how one should start with solving a Design Problem given in an Interview.

Approaching a Design Problem

1. Breaking Down the Problem

When you are given a Design Problem start breaking it down into small components. These components can be Services or Features which you need to implement in the System.

• Initially, a System given to be designed can have a large number of features and you are not expected to design everything if it’s an Interview.
• Ask your interviewer about the Features you are planning to put in your system. Is there anything else you should be putting there? Any Feature? Any Service? … Ask!

2. Communicating your Ideas

Communicate well with the Interviewer:

• While designing the system keep him in the loop.
• Discuss your process out loud.
• Try to demonstrate your design clearly on the whiteboard with flowcharts and diagrams.
• Describe your ideas to your interviewer, how you have planned to tackle the problem of scalability, how you will be designing your database, and many others.

3. Assumptions that make sense

Make some reasonable assumptions while you are designing the System.

Suppose you have to assume the number of requests the system will be processed per day, the number of database calls made in a month, or the efficiency rate of your Caching System. These are some of the numbers you need to assume while designing. Try to keep these numbers as reasonable as possible. Back up your assumption with some solid facts and figures.

Important points to consider when designing a software system:

1. Scalability: The system should be designed to handle increased loads and be able to scale horizontally or vertically as needed.
2. Performance: The system should be designed to perform efficiently and effectively, with minimal latency and response time.
3. Reliability: The system should be reliable and available, with minimal downtime or system failures.
4. Security: The system should be designed with security in mind, including measures to prevent unauthorized access and protect sensitive data.
5. Maintainability: The system should be designed to be easy to maintain and update, with clear documentation and well-organized code.
6. Interoperability: The system should be designed to work seamlessly with other systems and components, with clear and well-defined interfaces.
7. Usability: The system should be designed to be user-friendly and intuitive, with a clear and consistent user interface.
8. Cost-effectiveness: The system should be designed to be cost-effective, with a focus on minimizing development and operational costs while still meeting the requirements.