What it shows:
A geographical or logical site map overlaying where the software applications are hosted (e.g., primary data centres, cloud regions) against the physical locations of the end-users accessing them.
Why it’s needed:
Latency planning and data sovereignty. This is used to prove that network latency and bandwidth constraints for remote sites have been accounted for. Crucially for regulated environments, it visually proves data residency compliance by showing that sensitive applications and their users remain within authorized geographical or national boundaries.
When to use it:
Highly recommended for SADs and HLDs on distributed, multi-site deployments, hybrid cloud architectures, or any project where user experience could be heavily impacted by the physical distance to the host servers.
When NOT to use it:
Generally best to omit for localized, single-site deployments where all users and servers reside in the exact same building or campus. It should also be skipped for purely internal backend integrations where no human users are interacting with the system across a Wide Area Network (WAN).
Example:
