Hi Nilesh, if we are talking only about the efficiency of communication of LLD to go up, which should be the case in my view, sequence diagrams have worked best for me when it comes to both HLD and LLD. For more complex situations, a class diagram or activity diagram can help to provide a high level view before a deep dive, but a sequence diagram is what hits the nail. That's where we can represent all user journeys, and we can talk about failures, retries, exception, handling, multi-threading - almost every minute detail about the execution.

I have felt throughout my career that if I or any of my team members come up with a sequence diagram, the communication is seamless, in turn the review is seamless and the final execution of the design doesn't need back and forth.

I use https://sequencediagram.org/ for building sequence diagrams since the UX is simple and effective, and the tool lets me share reusable diagram links without the need for login.

There can be an initial hindrance because it is like a new scripting language to learn, but I found it quite simple after a couple of attempts. Some instructions mentioned here : https://sequencediagram.org/instructions.html

Diagrams are mere representation and based on usecase what you need to explain diagram has to be chosen. I would personaly give less preference to diagrams. The most important thing is how you do LLD. Do you follow SOLID principles, do you follow DDD architecture, do you follow lose coupling architecture. Is your design Scalabale, Maintainable? Those things one should focus on primary

While approaching LLD , you can start with activity diagram which will help you and the interviewer to be on the same page on entire interview how the actors should interact with each other as a part of requirements. Once you are clear with the requirements , you can concentrate on class diagram and how different classes will interact. On basis of certain factors , you can determine the choice of db on every entity you mentioned. System Design round would always be a open ended discussion about showcasing you knowledge and experience in a given timeframe.

Hi Nilesh,

In approaching Low-Level Design (LLD), the choice of diagrams largely depends on the aspects of the system you're focusing on:

1. Class Diagrams are central to LLD, especially in object-oriented design (OOD). They detail the system's classes, attributes, methods, and the relationships among classes. This is key for understanding how different parts of the system interact at a code level.
2. Use Case Diagrams may be considered more of a high-level view but can support LLD by clarifying how users (actors) will interact with the system. This helps in ensuring that the class design aligns with user requirements and scenarios.
3. Activity Diagrams are useful for modeling the flow of control or data. They're excellent for detailing complex business logic, workflows, or processes within the system, complementing the static view provided by class diagrams with a dynamic perspective. I find them to be very useful for the applications that require such detailed designs.

Most people favor Class Diagrams for LLD due to their direct correlation with code. Use Case and Activity Diagrams are often used to supplement understanding and ensure the design meets functional requirements and handles processes correctly.

Hi Nilesh,

Hope the below answers your question, please let me know if you need any further clarifications.

1. Use case Diagram: This diagram provides a high-level view of the system’s functionality from the user’s perspective. It helps in understanding the system’s main functions and the roles of different users. It’s crucial during the requirements gathering phase but not typically used in low-level design.
2. Activity Diagram: This diagram depicts the dynamic aspects of the system, showing the sequence of activities and how they are related. It’s useful in understanding the system’s workflow and can be used in both high-level and low-level design to illustrate how different components interact.
3. Class Diagram: This diagram is essential in object-oriented design. It shows the static structure of the system, including classes, attributes, operations, and relationships. It’s crucial in low-level design as it provides a blueprint for coding.

Low-Level Design Principles

Low-level design focuses on the design of individual components and how they interact. It involves principles such as:

• Modularity: The system should be divided into separate modules based on functionality.
• Information Hiding: Each module should hide its internal details from other modules.
• Cohesion and Coupling: Modules should be highly cohesive (i.e., they should only perform related tasks) and loosely coupled (i.e., they should have minimal dependencies on each other).

Diagrams for Low-Level Design

While all diagrams can provide valuable insights, some are particularly useful in low-level design:

• Sequence Diagram: This diagram shows the interaction between objects in a time-sequenced manner. It’s useful for understanding the system’s behaviour and the communication between objects.
• State Diagram: This diagram shows the different states an object can be in and how it transitions from one state to another. It’s useful for designing objects with complex lifecycles.
• Component Diagram: This diagram shows the organization and dependencies among a set of components. It’s useful for visualizing the physical aspects of an object-oriented system.
• Deployment Diagram: This diagram shows the physical resources in a system, including nodes, components, and connections. It’s useful for understanding how software components are deployed on hardware.

During LLD you will primarily use Class Diagrams. You can explore UML, how and where to use the different elements like rectangles or other shapes, relationships like inheritance, association, aggregation, etc in your Class Diagrams. The class diagram should present the blueprint for the code structure.

In an interview setting with limited time, prioritize the Class Diagrams. If time permits, you can briefly mention using use case diagrams to ensure your design aligns with functionalities and activity diagrams for complex workflows only. However, focus your explanation and effort on the class diagram.

Hey Nilesh,

In Low-Level Design (LLD), different diagrams help understand and plan how a system works.

Class Diagrams show classes, what they have, and how they connect, like a map of the code. Use Case Diagrams focus on how people or things use the system, making sure it meets their needs. Activity Diagrams show the steps or actions in the system, helping with complex processes. Starting with Use Case and Activity Diagrams ensures we know what the system needs to do before diving into specific classes. Sequence Diagrams are super helpful for showing how things happen in order, making it easy to talk about what goes right or wrong. They're like detailed scripts for the system's actions.

Even though Class Diagrams are popular, combining them with Use Case, Activity, and Sequence Diagrams helps everyone understand and plan the system better. Each diagram has its role in making sure the design makes sense and works well.

Hope this was helpful!