Build a client-path map
| Input | What to record |
|---|---|
| Client geography | Concentrations of active connections and the routes they currently use. |
| Platform dependencies | The required path between the access layer and the other platform components. |
| Load pattern | Connection peaks, reconnect events and observed resource pressure. |
| Failure requirement | Which unavailable component or route the design must tolerate. |
Use observations from representative client locations rather than the distance between cities alone. Record the measurement period and connection type so a regional comparison can be repeated.
Pilot one change with a clear success condition
Select a candidate region, define the intended client group and compare the path before and after the proposed change. Watch for a new bottleneck between components: improving the first segment of a connection does not prove an improvement across the whole service. Include reconnect behaviour in the test plan.
Agree how the tested clients are assigned and how that assignment is reversed. Use the supported platform and provider procedures; avoid an uncontrolled change to production routing merely to gather a benchmark.
What the deployment brief should contain
The output should identify component locations, client coverage, dependencies, capacity assumptions, monitoring and the organisation responsible for each change. Set a review trigger such as a change in client geography or recurring access pressure. Server count follows this model; it is not a substitute for it.
An access layer in another region is not automatically a complete disaster recovery environment. If recovery is required, document the other services and usable data state needed to resume operation. Bring this map to an MT5 deployment review with the existing connection evidence.