Measure demand at the access boundary
Collect active client regions, concurrent connections, login bursts and the conditions during peak windows. Record the network path and whether a reported delay occurs before login, while receiving data or during another workflow. These are different observations and should not be collapsed into a single latency average.
MetaQuotes describes MT5 as a distributed platform. The permitted topology and available access roles still depend on the platform arrangement and configuration being proposed. Confirm those boundaries before deciding where additional nodes can be used.
Evaluate count through operating scenarios
| Scenario | Question | Evidence needed |
|---|---|---|
| Normal busy window | Which regions and connections create demand? | Regional observations and node-level measurements |
| Planned maintenance | Can the agreed workflow continue with a node unavailable? | A controlled maintenance or load-test record |
| Unexpected interruption | Where do affected clients reconnect and what constrains the remaining path? | Connection/recovery observations and dependency map |
| Growth | Which measured threshold triggers another review? | Baseline trend and approved expansion criteria |
A spare node is useful only if the remaining paths, core services and connected systems can support the agreed scenario. Node count is not itself an availability guarantee.
Make the expansion decision measurable
Illustrative review: a brokerage’s traffic becomes concentrated in a new region. The team compares regional connection observations with the current topology and then validates a proposed access change against representative activity.
Document the reason for each node, its operating owner and the test used to accept it. Retain the observations so a later review can distinguish geographic growth from a configuration problem or an upstream constraint. The infrastructure builder can organise the initial brief; final node placement needs the reviewed environment and measured evidence.