While Class, ER, and Component Diagrams model your system's logical and structural code boundaries, they do not show where those software elements actually run. To bridge the gap between logical software components and physical hardware infrastructure, engineers use the Deployment Diagram.

In Low-Level Design (LLD), a Deployment Diagram maps out the physical execution topology of the system—illustrating exactly which software artifacts are deployed onto which hardware nodes and how those devices communicate over a network.

Key ideas:

  • A Deployment Diagram provides a static view of the real-world, physical runtime environment of an application.

  • It models physical hardware configurations (servers, devices) and execution environments (virtual machines, containers).

  • It highlights network communication paths, protocols, and deployment bottlenecks early in the architectural phase.

Core Components of a Deployment Diagram

Deployment Diagrams introduce a specialized set of three-dimensional geometric notations to model real-world infrastructure:

  • Node (3D Cube): The foundational element representing a physical computational resource or execution environment. Nodes are split into two subtypes:

    • Device Node: A physical piece of hardware with processing capability (e.g., ApplicationServer, DatabaseServer, IoTDevice).

    • Execution Environment Node: A software-based container or environment running inside a physical device (e.g., DockerContainer, JVM, OS_Linux).

  • Artifact (Stereotyped Box): Represents the actual physical file, compiled binary, or executable module generated by your code (e.g., order_service.exe, database_schema.sql, app_bundle.jar). In diagrams, artifacts are drawn nested inside the node cubes where they are deployed.

  • Communication Path (Solid Line): A connection line linking two node cubes, explicitly labeled with the network protocol or middleware channel used for data transfer (e.g., HTTP/HTTPS, TCP/IP, gRPC, JDBC).

Step-by-Step Modeling Example: 3-Tier E-Commerce Architecture

To see how a deployment design coordinates topology, consider a production-ready application layout:

"A client accesses an online store through a desktop web browser (Client Device Node running a Web Browser execution environment). The browser hits a load-balanced API Gateway Server via HTTPS. The API Gateway forwards requests to an isolated Application Server Container using gRPC. Finally, the application container reads and writes transactional rows to a dedicated, high-availability Database Cluster over a secure TCP/IP connection via JDBC."

Mapping Deployment Diagrams to Configuration and Initialization

Unlike other structural diagrams, a Deployment Diagram doesn't map directly to your inner class logic. Instead, it maps directly to your Deployment Manifests (Docker Compose, Kubernetes YAMLs), Build Scripts (CMake, Makefiles), and Configuration Settings.

Here is how a C++ system initialization sequence models these physical node connections, utilizing configuration variables to dynamically handle network protocol boundaries:


Execution Demonstration


Common Pitfalls in Deployment Modeling

  • Confusing Components with Artifacts: A Component is a logical grouping of classes inside your design phase (e.g., PaymentController). An Artifact is the physical file produced after compiling or packaging (e.g., payment_service.jar, app.war). Do not put logical components directly onto deployment nodes without formatting them as compiled artifacts.

  • Omitting Communication Protocols: Drawing plain solid lines between your 3D node cubes without labeling them is a major design failure. Network, DevOps, and Security engineers must know exactly what protocol flows over that connection wire (HTTPS, gRPC, SFTP) to configure firewalls and load balancers correctly.

  • Over-Modeling Trivial Client Environments: Avoid wasting time drawing complex multi-node structures for standard client machines unless they contain specialized physical devices (like POS receipt printers or custom IoT sensors). Simply group basic end-users into a single Client Machine cube running a web browser.

Summary

  • Deployment Diagrams map out the concrete, physical architecture, network pathways, and hardware host nodes of a software solution.

  • 3D Node cubes clearly segment physical device hardware from virtual execution environments like containers or operating systems.

  • Nesting code artefacts inside deployment cubes bridges the gap between your abstract code repository and its real-world physical runtime environment.