The Assembly Manual and Execution Layer
What it is:
If the Solution Architecture Document (SAD) is the architectural blueprint, the Low-Level Design is the step-by-step assembly manual. It takes the physical boundaries established in the SAD and translates them into strict, component-level configuration instructions. The goal of an LLD is to leave absolutely nothing to the imagination. If a build team has to guess how to configure a setting, the LLD has failed.
What goes inside:
- Granular Network Details: Exact IP schemas, subnets, VLAN tags, routing protocols (e.g., specific BGP autonomous system numbers), and explicit NAT translation rules.
- Component-Level Configurations: Specific registry keys, exact service account names (excluding passwords), local group policies, software dependencies, and application tuning parameters.
- High-Availability Mechanics: The literal cluster configurations, heartbeat network IPs, load-balancer health-check parameters, and failover timeout values.
- Pointers to the Build Matrix: For massive, repetitive configurations (like provisioning 50 identical web servers or writing 200 firewall rules), the LLD document should outline the logic of the configuration, and then explicitly reference an attached Configuration Spreadsheet for the raw, row-by-row data.
What NOT to put inside:
- Strategic Business Context: Value streams, business capability maps, and ROI justifications. The deployment engineer does not need to know why the board funded the project; they only need to know how to build it to standard.
- Conceptual Diagrams: Leave the high-level Phase 1 and Phase 2 diagrams out. A conceptual data map adds zero value to an engineer trying to configure a SAN switch.
- Vendor Selection Criteria: The decision is made, the hardware is bought; the LLD is purely about how to configure it.
The Audience:
This document is for the people on the ground. The primary readers are Build Teams, Deployment Engineers, Network Administrators, Database Admins (DBAs), and 3rd-Party Contractors who are responsible for the physical construction and configuration of the environment.
When to use it:
- Highly recommended for standardizing builds: It is the primary vehicle for ensuring that Best Practices, security baselines, and organizational standards are consistently applied across the infrastructure.
- Highly recommended to prevent “Configuration Guessing”: By defining the exact settings, you eliminate the risk of engineers “personal preferences” configurations. It ensures the environment is built to the architects’ design, rather than the engineers’ personal preferences.
- Essential for configuration consistency: It is the only way to guarantee that Development, Test, and Production environments are truly identical, preventing “it worked in Dev” debugging nightmares.
When NOT to use it:
- During executive pitches or budget approvals: Showing an LLD to a Project Sponsor is a fast track to completely derailing a strategic meeting with technical minutiae.
- For true “Black-Box” SaaS deployments: When deploying a purely managed Software-as-a-Service solution (like Salesforce or Microsoft 365), the vendor entirely controls and obscures the underlying compute, networking, and server configuration. An infrastructure LLD is usually redundant here.
