Let’s take a look under the bonnet of Tinkoff Investments. We talked with API Direction Team Lead
What are the peculiarities of using the API in modern exchange trading? What challenges in development does a large broker face? Alexander Volkov, a lead of the API direction, answered all these questions in the Kotelov digital finance podcast. In this article, we are sharing a high overview of the key insights from the conversation.
Who needs the Tinkoff Investments API?
If you break down the audience into segments, it will be as follows:
1. Third-party services that allow clients to create robots, conduct analytics, and calculate profitability
2. Algo traders who want to automate their intraday operation. If a client trades days or weeks, it is easier to place an order through a mobile app or a web terminal
3. People who exploit market inefficiencies at the instant. For example, when there was a large spread between buy and sell — the robot has this security. It can buy and sell at the same time + act as a marketmaker.
Algorithmic traders are individuals and legal entities who use software to buy and sell assets automatically.
What’s inside the second API version?
The first version of the Tinkoff Investments API was a branch from the existing version of the mobile app and the web terminal. The second version still continued to support REST-API requests, although it was based on gRPC.
Rest
It was originally used in the first version. The second version can also be used via Rest.
gRPC-веб
Allows streaming of market quotes for browser-based web apps
gRPC
1. You can generate the required program code in any programming language and connect API support under the contracts
2. It supports versioning well:
— all fields are numbered;
— old fields will be supported after adding any new ones.
3. It supports request deadlines
💡 Situation
The request is executed for a very long time, for example, due to some kind of incident on the exchange. The client has a 5 seconds timeout set. The request goes to the server and takes 10 seconds, while the client still has the same 5 seconds.
As such, the client drops the connection, but we continue to execute it. It is important to consider that there are many services inside Tinkoff Investments, so the request path is not trivial. As a result, one service can send a request to another one, a third one, and so on, although the client no longer needs a response.
In the case of gRPC, we set a bar up to which the request must be executed — a deadline. If the deadline is missed, we interrupt further processing, just like the client.
Why did you use gRPC instead of web sockets?
Using gRPC provides several benefits:
· modernity
· performance
· binary
💡 The main reason for using gRPC is to unite services that provide web socket translation and those providing personal handling of single requests, as well as to pack everything into one channel.
What about the database? An interlayer or your own local base?
The API direction in Tinkoff Investments is closer to an interlayer.
However, there are tasks for rate limiting — restricting the flow of requests iriginating from a specific user. There are also logging tasks — we use Postgres within our team for them.
All other requests are proxied further to the internal investment services.
Project in figures
We usually get about 1 mln orders per day. Talking about peak values, they reach 20,000 requests per second.
Is it a paid or free service?
Basically, the API is free, but we stick to the dynamic limiting tactics, based on the client’s trading activity.
We faced a problem when clients put heavy load on the backend. If a client executes many orders and brings a lot of fees, the limits will be very large. If a client trades little or does not trade at all, they will have standard limits on orders.
💡 The more a client trades, the more requests they are allowed to send
How is caching built?
We have two types of cache:
1. Redis
2. Cache by trading statuses; it is used for services where the speed of notifying users about any market events is critical.
Balancer: NGINX or self-written service?
We are using the envoy primary balancer. They also have rate limiters attached.
There were many DDoS attacks in 2022. They targeted not specifically the API — only separate mad robots cause problems on it. The entire bank structure is usually subjected to DDoS, and we get affected as well.
What are mad robots? Do people lose money because of them?
It is important to understand the process. The following situations may happen:
💡 The order comes to the API; the broker checks it for sufficiency of funds; the specified amount is hold and blocked on the account; after that it is sent to the exchange.
If it takes long for the limits to recalculate, the following situation occurs:
💡 The order is executed, but the position has not been updated yet. The robot thinks that the position needs to be bought or sold, although it has already been executed. As such, the strategy of the client using the robot “breaks down”: they can accidentally buy or sell extra positions, which is especially dangerous when trading with leverage. Ultimately, a series of such errors can result in the portfolio loss (Margin Call).
Stack
We use many languages, but mostly Java. We used GO before, but decided to ditch it. There was no fundamentally technical reason or problem — it just turned out that specialists working in this language are easier to find on the market.
How do you fight fraud?
Actually, it is the exchange that fights fraud, rather then us. They set up anti-fraud frameworks and then block clients. Unfortunately, we cannot influence this process.
How do you measure user satisfaction?
· We monitor the number of failures.
· We monitor the speed of the order execution.
· We carry out the usual customer development: do you like or dislike the product, and so on.
As a rule, 20–25% of users are fully satisfied.
The main API problem in Tinkoff Investments
Speaking about main API problem, we offer experienced readers to guess: which architectural difficulties did Alexander and his team face? Suggest in the comments
