Trade Processor architecture: an interview

Author: Alexey Kutsenko

One of the profound concepts of building aggregators is to choose, whether it is going to be a centralized or a decentralized system. Your first option is to build your servers, which creates a kind of a pool where you connect all LPs, Exchanges and “givers”, and all the takers. These exchanges are usually located in the same areas - TY3, NY4, LD4, etc. Another option is to go ‘decentralized’, where you build and place an aggregation engine on the same machine as your trading platform, or a separate machine.

There are pros and cons in both approaches, and we decided to ask Alexey — the visioner of TFBs products — why the company decided to make it decentralized and what it gives to the brokers.

Q: Let’s start with the architecture of Trade Processors. Could you please tell us the thought process behind designing it the way you’ve done it?

A: Product architecture is a strategic choice: do you want to make life easier for yourself or your clients. If we set up a single centralized system — it’s easy for us, there are a number of benefits for the product, it’s easier to update, manage, and maintain. However, the values that we had are — transparency, efficiency, and convenience for clients. We want to make the bridge a daily helping instrument, not a complicated system. And we decided that all infrastructure must be on the client’s side. It gives freedom to create the system for custom needs, to change it and adapt it for specific scenarios. With such an approach, brokers are not dependent on others — we don’t have to confirm every single change with every single customer. As a result, we are more flexible when it comes to setup, settings, load control, and general management.

We are providing hosting services as well, so we can install the bridge on our end. Clients would then treat us like a cloud solution where nothing is running on their side. Still, in that case, all maintenance and support are done individually.

If there is a requirement for specific options or changes, or if the client has an update scheduled, and they need an urgent system restart in the middle of the day — we can do all that for one client account only, not affecting the rest of the customer base as it would be with a centralized system.

In our opinion, the way we’ve architected our solution is simply more convenient. It might be a little more resources-consuming if we roll out a big update as every client must be updated individually. However, in our experience, it’s rarely a concern as all clients prefer to run updates on their own schedule anyway.

Q: How scalable is such architecture? How many platforms, providers, API connectors, etc can we add to it?

A: It’s not so much about the numbers, it’s more about data volumes. We can connect 10 trading platforms and have low volume, or 2 platforms with 1000 orders per second. We scale based on requirements but our system enables us to split it into entirely independent components, allocate a pool of Tier 1 clients, and migrate them to separate more powerful servers to meet their particular needs.

Again we are going back to our point about flexibility — we are not constrained when it comes to scalability. We can have 1 system installed that would service multiple platforms and providers, as well as we can have multiple bridges installed around a single high-load server. Every environment and every setup is very different, so it’s best to look into each case separately and work out the configuration for every individual client.

Q: Nowadays, there is a lot of buzz about security — how is your bridge protected from attacks?

A: Security is, of course, one of the main concerns for us. The way we are protecting the system would depend on how it is rolled out. When we install TP inside the broker’s infrastructure, we can set a limit on a network level for TP to only communicate with LP and trade platforms. So, in fact, the TP components would be unavailable from the outside, except for maybe the web interface, which has no effect on system performance. We enable our clients to limit the access to system settings across their offices.

Q: What happens if one of the components fails, and is it possible at all?

A: All TP components are launched as services, and they are designed to automatically restart in case of unauthorized failure. There should not be a failure, but in those unlikely cases, if and when it fails — clients don’t need to worry as it will restart instantly.

Q: Does your system allow you to improve execution speed, and why would it be important?

A: Execution speed is, of course, very important as the faster execution is, the better pricing we receive. So how do we increase the speed? First of all, we can scale by adding an extra Trade Processor and extra server to offload some of the balance from MT4/MT5 if it gets to a point where the system can’t handle it. The other way to manage the speed would be to physically locate the bridge close to clients’ server to reduce network latency. It’s worth noting that the distance from LPs would stay the same, but it would significantly help with B-book scenarios.

Q: Trade Processor enables us to connect multiple platforms, but what if these platforms are located on different continents? Does it make sense to have two bridges in this scenario? Would they still have a single web?

A: Well, it depends on the end goal. If servers are on different continents and speed is extra critical, then I would recommend having 2 bridges. In other scenarios, we need to run the tests with each individual setup and see how it performs. Different continents do not equal worse speeds. Let’s take China and Vietnam as an example — those 2 countries are close geographically, but they won’t have a great connection because of the Chinese firewall. In scenarios where there are two bridges installed, our clients receive separate logins for the management of the teams, which is more convenient, in our opinion. Clients can easily switch back and forth to view the statistics.

Q: What are the benefits of a decentralized system versus centralized?

A: I would say that pretty much everything we’ve discussed just now outlines the benefits of decentralization. Our system is flexible, stable, fast, and customizable. Every architecture has its pros and cons, and throughout our 10-year experience, we’ve come to understand that decentralized systems work best for our clients and us.

Q: How quickly can new liquidity providers connect to the system if it’s not centralized?

A: It’s rather easy. If it is a specific liquidity provider for a particular client, then we quickly design a patch for it and update this client right away. If the goal is to add a certain liquidity provider to everyone in the customer base, then it might be more resource-consuming in theory. Yet in practice, it’s a rare case.

Fill the form below to get free trial:
By signing up, you agree to our Terms and Conditions
This site uses cookies and other tracking technologies to assist with navigation and your ability to provide feedback, analyse your use of our products and services, assist with our promotional and marketing efforts, and provide content from third parties. Cookie Policy