System Context Deployment Diagram

What this diagram shows

A system context deployment diagram presents the physical or virtual infrastructure nodes that make up your system and how they connect to external dependencies. It shows where components run (servers, containers, databases, message queues), the communication protocols between them (HTTP, gRPC, TCP, message bus), and the boundary between your system and third-party or legacy systems. The diagram emphasises deployment topology rather than code structure, making it useful for operations, infrastructure planning, and identifying network boundaries and single points of failure.

Key components

• Application Node — Represents a deployed instance of your application running on a specific server, VM, or container where business logic executes.
• Database Server — Stores persistent data and handles read/write operations for the application nodes that depend on it.
• External System — Third-party service, legacy system, or SaaS offering outside your control that your system integrates with.
• Message Queue or Event Bus — Decouples applications by routing asynchronous messages between producers and consumers across deployment boundaries.
• Load Balancer — Distributes incoming traffic across multiple application nodes to balance load and enable failover.
• Reverse Proxy or API Gateway — Sits between clients and application nodes to handle authentication, rate limiting, request routing, and protocol translation.

When to use it

Use this diagram when you need to show how your system is physically deployed, when discussing infrastructure changes, capacity planning, or disaster recovery strategies. It is essential for cloud migration discussions, multi-region deployments, and conversations between developers and operations teams. Also valuable when onboarding new team members to the runtime architecture or when identifying network latency and dependency risks.

Common mistakes

• Mixing logical architecture (classes, modules) with deployment nodes instead of keeping focus on where software runs and how nodes communicate at runtime.
• Omitting external systems and leaving the system boundary ambiguous, which obscures what your team owns versus what third parties maintain and could fail independently.
• Showing every internal dependency arrow instead of highlighting only the significant inter-node communication paths, which clutters the diagram and obscures the real deployment topology.

Adapting it to your system

Start by listing every distinct runtime entity in your system: application servers, databases, caches, queues, and load balancers. Then identify external dependencies: payment processors, email services, identity providers, or legacy mainframes. Draw your system boundary clearly. Use arrows only for significant communication paths and label them with the protocol or message type. For cloud deployments, add availability zones or regions. For containerised systems, show orchestration layers (Kubernetes clusters). Remove internal RPC calls unless they cross deployment boundaries.