High Level Design and Low Level Design are often discussed together, but they serve different purposes. Confusion between the two can lead to documentation that is either too vague to build from or too detailed to help decision-makers understand the architecture.
A useful design pack should create a clear progression from business and technical requirements through to implementation detail. HLD explains the architecture and major design decisions. LLD explains how that architecture will actually be configured and built.
What a High Level Design should do
The HLD should describe the target solution at an architectural level. It explains the major components, their relationships, the design principles being applied and the important decisions that shape the solution.
It should answer questions such as: What are the main technology components? How are environments separated? How does traffic flow? Where are the trust boundaries? How is resilience achieved? How do users and systems authenticate? How does the solution integrate with other services?
The audience is usually broader than the implementation team. Architects, technical leads, security teams, service owners, programme managers and stakeholders should be able to use the HLD to understand the proposed solution without needing every configuration parameter.
Typical HLD content
The exact structure depends on the project, but a good HLD commonly includes scope, requirements, assumptions, constraints, current-state context, target architecture, network design, identity, security, resilience, integration, monitoring, backup and disaster recovery.
It should also document important architecture decisions and any areas that still need validation.
Diagrams are particularly valuable at this level. A good architecture diagram should show the relationship between systems clearly enough that someone unfamiliar with the environment can understand the design.
What an HLD should not become
An HLD should not turn into a collection of screenshots, command outputs and configuration tables. Those details may be useful evidence during discovery, but they do not necessarily explain the architecture.
Similarly, an HLD that only contains broad statements such as “the solution will be secure and highly available” is not useful unless it explains how those outcomes are achieved.
The right level of detail is enough to understand the design and review whether it meets the requirements, while leaving implementation-specific settings to the LLD.
What a Low Level Design should do
The LLD takes the approved architecture and translates it into implementable detail.
It should allow a competent engineer to build or configure the solution consistently. That means specifying the information that would otherwise require the engineer to make design decisions during implementation.
Depending on the technology, this can include resource names, IP ranges, subnet definitions, route tables, firewall rules, security groups, IAM policies, instance sizes, storage configuration, database parameters, backup schedules, monitoring settings, DNS records and certificate requirements.
DNC’s Corporate Architecture and Technology Services include current-state discovery, HLD, LLD and transformation planning.
The LLD should trace back to the HLD
The two documents should not describe different solutions.
If the HLD states that application tiers are segmented, the LLD should show the actual subnets, security controls and routing that enforce that segmentation. If the HLD requires least-privilege access, the LLD should define the groups, roles or policies used to implement it.
This traceability makes design reviews easier and reduces the risk that the implementation drifts away from the approved architecture.
Current-state documentation has a different purpose
When reverse engineering an existing environment, it is useful to separate current-state documentation from target-state design.
A current-state pack should describe what is actually deployed today, including known gaps and inconsistencies. The target HLD can then explain what should change. The LLD provides the implementation detail for those changes.
Mixing current and target state together makes it difficult to understand which components already exist and which are proposed.
This separation is particularly important during cloud migration and modernisation. DNC’s Cloud Architecture and Engineering work includes current-state discovery and target architecture across OCI, AWS, Azure and hybrid platforms.
Requirements should drive both documents
Design documentation is strongest when it can be traced back to requirements.
Availability, recovery, security, performance, compliance, supportability and cost requirements should influence the architecture. Otherwise, the design risks becoming a technically interesting solution without a clear business justification.
For example, multi-region architecture may improve resilience, but it also introduces cost and operational complexity. The design should explain which requirement justifies that complexity.
Security belongs in both HLD and LLD
Security should not be confined to a separate paragraph saying that best practice will be followed.
At HLD level, the document should explain the security model: trust boundaries, identity principles, network segmentation, encryption approach, logging and privileged access.
At LLD level, those principles become concrete settings such as firewall rules, IAM permissions, encryption configuration and log destinations.
For independent review of infrastructure, cloud and application security, DNC also provides Cyber Security and Ethical Hacking services.
Operational requirements need design detail too
Architecture is not finished when the system can be deployed. It also needs to be operated.
The HLD should identify the operating model and major support responsibilities. The LLD should provide enough information to configure monitoring, backups, alerts, maintenance tasks and administrative access.
Where third parties or MSPs are involved, the boundary between technical design and operational ownership should be explicit.
Keep decisions separate from implementation notes
One useful approach is to record key architecture decisions explicitly. This provides a clear explanation of why a particular option was chosen and what alternatives were considered.
The LLD can then focus on how that decision is implemented. This prevents important design rationale from disappearing inside a configuration table.
How much detail is enough?
The right amount of detail depends on the audience and the complexity of the system.
A useful test for an HLD is whether another architect can understand and challenge the design. A useful test for an LLD is whether another competent engineer can implement the solution without having to invent missing design decisions.
More pages do not automatically mean better documentation. Clarity, accuracy and traceability are more important than volume.
Common documentation mistakes
One common problem is writing the HLD after the system has already been built. The document then becomes a retrospective description instead of a design control.
Another is making the LLD too generic. Statements such as “configure appropriate firewall rules” do not remove implementation ambiguity. The actual rule set belongs in the LLD or an associated controlled configuration schedule.
Documents also become unreliable when ownership for updating them is unclear. Design documentation should be treated as part of the solution lifecycle, not as an artefact that becomes obsolete immediately after handover.
What good looks like
A good HLD tells a clear architecture story. It explains the requirements, components, relationships, controls and major decisions. A good LLD then translates that architecture into concrete, buildable detail.
Together they should allow reviewers to understand why the solution is designed the way it is, allow engineers to implement it consistently and provide operations teams with a useful technical reference.
Conclusion
HLD and LLD are complementary rather than interchangeable. The HLD explains what is being designed and why. The LLD explains how that design will be implemented.
When both documents are built from accurate discovery and clear requirements, they reduce ambiguity, improve technical review and create a stronger handover into implementation and operations.
If your organisation needs current-state discovery, architecture documentation or HLD and LLD development, see DNC’s Corporate Architecture and Technology Services or contact DNC.