Hosting MT5 and a liquidity bridge on the same server is a bad idea. Here’s why.

Author: Spartak Vyucheiskii

The world of fintech software is fast-paced, demanding, and risky.

Nearlys half of the conversations that we have with clients are centred around risk management in one way or another:

• How to protect traders and their funds.
• How to protect your own business.
• Ensuring there is no downtime or freezes.
• Staying flexible to make the most of changing markets.

There are also basic rules that aren’t discussed very often because they’re not as “hot” as AI, your own trading platforms, or other flashy tools that make you look good when you talk about them. Despite that, these basics are often what keep the business not only afloat but truly secure and thriving.

Those basics are, for example:

• Running regular backups to protect data.
• Keeping the software and dependencies up-to-date.
• Following installation best practices to prevent disasters.

Periodically, we get requests about hosting both the MT5 server and the liquidity bridge on the same piece of hardware as a way to optimise costs. This is a rather worrisome tendency because it puts the brokers doing it at risk. That’s why today we’re going to dive deeper into this topic and showcase why you might want to refrain from this practice.

Why would a company want to host MT5 and the liquidity bridge on the same server?

There are several reasons why companies might want to host MT5 and the liquidity bridge on the same server. Here, we will discuss two of the most important reasons:

• Performance optimisation
• Cost optimisation

If we are talking about performance, installing MT5 and the bridge on the same physical machine significantly decreases the data transmission time between these two nodes.

At the same time, from a cost perspective, keeping the modern bridging solution on a separate server might double the hardware expenses.

While hosting MT5 and the liquidity bridge on the same server sounds like a good idea due to performance and cost benefits, there are some hidden risks that could lead to significant problems.

The main driver for squeezing both MT5 and a liquidity bridge on the same server is cost.

Putting them on separate servers would require two pieces of hardware, which doubles the cost of purchasing and maintaining the environment. Many software products sometimes require more resources than they actually consume, so naturally, optimising the hardware usage and, therefore, the overall cost is a common requirement from the management.

Again, installing and running MT5 and a bridge on the same server sounds like a good idea on paper. The hardware takes up less space, and there are fewer costs. What’s not to love, right?

What issues are you likely to encounter if you host MT5 and the liquidity bridge on the same server?

Unfortunately, whenever you find a way to optimise resources that’s not widely accepted, there is usually a catch.

When we talk about cost optimisation, we usually assume that the bridge will be installed on the MT5 server without increasing hardware performance. And even if the major metrics are far from the machine limit, there are some negative performance indicators which would be evident when two solutions, like the trading platform and bridge, are installed on the same machine (e.g., the storage read and write queue size).

This situation might lead to numerous unexpected problems, the most common of which are:

• Quotes delay
• Execution delay
• General connection issues
• Trading and history data losses

Even with this list of issues, we can easily conclude which risks would be created by this attempt at “cost optimisation”:

• Potential vulnerabilities of the environment
• Delayed quotes abuse
• Unsatisfied clients due to the execution issues

Add here the fact that it wouldn’t be possible to quickly resolve the issue and scale the system in case of an emergency. Also, do not forget that all these issues might arise even with a small load on the system. Suddenly, this optimisation doesn’t look appealing financially. The way to the best solution is to count potential risks, not potential benefits.

Another topic is performance optimisation. A boost in performance can be achieved only by avoiding several pitfalls:

• Your server for MT5 must be capable of hosting both of the applications at the same time. Pay attention to the bottleneck there – the speed of your storage device.
• Minimising the bridge components on the server is also a very important step to achieving the best performance. For example, modern bridges use database server applications, and installing them remotely will grant a huge performance increase.
• A personalised consultation with the bridge vendor regarding your specific case is the best thing that you can do for your business. Nobody has a better understanding of the bridging solution than the vendor, and a personal approach might prevent many risks.
• The additional load on the IT department in order to monitor the environment with more metrics and observe possible issues even faster than on a cluster with separate machines.

It is also good to mention that, in reality, on the MT5 platform, if you locate a server with the bridge close enough to a server with MT5, the benefits will be the same or negligibly different.

Brokers looking to have both MT5 and a bridge on the same server end up experiencing many unpleasant side-effects of such a configuration, including but not limited to:

• Quotes delay
• Maintenance issues
• Problem-solving delays, as the root cause of the issue is harder to track
• Performance issues caused by insufficient resources left on the server
• Additional expenses associated with technical issues

All this leads to:

• Productivity drop
• Waste of time
• Scalability issues

The risks that the broker creates outweigh the potential benefits every time.

So, most of the time, the broker saves a small amount of money per month but ends up spending tenfold.   

So, what’s the alternative?

There are two main alternatives:

• Some vendors (such as TFB) offer a “cloud” bridge version. It costs a bit more, but your vendor will take care of the hosting and monitoring to guarantee the system’s stability 24/7.
• Install the bridge on the server with the MT5 failover.- Most of the known issues will appear only after several hours of the bridge and platform working together (depending on the load) so there might be enough time to restore the main MT5 machine and switch the platform back.

As much as we’d love to offer a magical solution that would cut costs while ensuring perfect performance, it doesn’t exist. Putting MT5 and a liquidity bridge solution on the same server means putting your operations under many additional risks.

Ideally, they should be hosted on completely separate servers, but there is a compromise. At TFB, we can install our Trade Processor liquidity bridge on the server with the MT failover. There are still some risks associated with this, such as technical issues during the failover. However, the only situation where MT will fail over to the server with the Trade Processor is if there is an issue with the primary server where the MT is hosted. This means that the two only have to co-exist on the same piece of hardware for a short period of time while the incident is being resolved.

Bottom line

Both MetaTrader and a liquidity bridge are mission-critical solutions for any brokerage, hedge fund, or prop trading firm. While we support optimisation, there are areas of the infrastructure where you’re much better off investing more in a proper setup than constantly dealing with issues, risking your reputation, finances, and the business itself.

If you’re looking for ways to cut costs in your company, we offer many automation tools and also ways within the Trade Processor bridge itself that can help you optimise the processes without jeopardising the future of the brokerage. If you’d like to learn more, please email us at sales@t4b.com.