Place services deliberately
List the platform roles, connectivity services, reporting tasks, integration adapters and monitoring components. Mark their data flows, access needs and sensitivity to interruption. Separate a dependency that needs fast communication from a job that only needs a scheduled export.
For every separation, identify the operational benefit and the additional work it creates. Extra hosts require their own access, patching, monitoring and recovery arrangements. A larger diagram is not automatically a stronger architecture.
Evaluate the placement alternatives
| Option | Reason to review it | Dependency to check |
|---|---|---|
| Combined initial environment | A limited, understood workload and simple operating model | Contention between critical and scheduled work |
| Separated workloads | Different resource or change requirements | New network paths and integration failures |
| Additional regional access | Observed user geography and connection needs | Whether the core and external dependencies remain a single constraint |
| Recovery environment | An agreed continuity requirement | Data/configuration readiness and the procedure to activate it |
The platform version and available deployment rights constrain the permitted topology. Confirm the actual arrangement before applying a generic server layout.
Test a topology through an interruption
Illustrative planning exercise: a reporting service is unavailable while trading and account access remain healthy. The team checks whether other services continue as intended and whether the reporting backlog can be reconciled after recovery.
Then test the loss of a dependency shared by several hosts. This distinguishes workload separation from genuine failure-domain separation. The handover should contain service placement, communication paths, operating owners and the evidence used to accept each important boundary. Review that map whenever new components or regions are added.