The issue we encountered in Dfyn V2’s Incentivised Testnet and how we resolved it.
Over the past year, our team has been working in stealth mode, innovating decentralized exchanges. We wanted to address and rectify the existing pain points of Dfyn, but more importantly, we wanted to use this opportunity to provide a one-stop solution for all trading-related activities.
To realise this ambitious vision, we started our development process from the ground up and in this process we came up with a lot of innovative solutions like Concentrated Liquidity AMM, Onchain Limit Orders, RFQ Styled Orders, and more.
We released an incentive-based testnet where users could earn tokens for achieving particular goals in order to determine the extent to which these services would go.
Although people were generally enthusiastic with this testnet, we did see some issues during busy hours when people couldn’t see their Liquidity Positions or Limit Orders on the interface (UI).
After investigating the problem, we determined that the issue was caused by a failure in the subgraph’s Remote Procedure Call (RPC) system. In our efforts to maintain complete transparency, we wanted to provide a detailed account of this incident in this article.
The problem we faced during DFYN V2’s incentivised testnet:
Some users who had created limit orders and pool positions, were unable to see their orders and positions on the interface, even though the transactions were processed and recorded on the blockchain.
This understandably leads to confusion and, if left unchecked, could be the cause of multiple points of failure.
Here’s why this took place.
GQL Issue and point of failure:
To run the testnet, we were using a single subgraph instance to fetch data for all components of the user interface.
The same subgraph was also used for multiple contract calls to retrieve contract-related data. Since there was a complete dependency on the subgraph, when the subgraph’s RPC (Remote Procedure Call) failed during the peak usage, it resulted in a single point of failure.
As a result, users were unable to view their limit orders and positions on their interface.
Naturally, the problem could not be resolved without the assistance of a third-party service provider (The Graph), and due to these constraints, the issue could not be addressed in a timely manner.
This caused inconvenience for the users and highlighted the need for a more robust and reliable data-fetching system. So here’s what we’re doing to make sure this never happens again.
Solution for Component’s rendering:
In order to address the issue of a single point of failure and improve the reliability of data-fetching in Dfyn V2 UI, we made several changes to the system.
First, we separated the subgraphs for each component of the user interface. This means that each component now fetches its data independently from its own dedicated subgraph instance. This approach helps to decrease the load on any one subgraph and improves the overall performance of the system.
Additionally, we optimised the subgraphs by reducing the number of contract calls that are made with each event. This results in faster loading of data and a more responsive user interface. Overall, these changes have significantly improved the reliability of the data-fetching system and have helped to ensure that users have access to accurate and up-to-date information about their orders and positions.
Setup with Service Provider:
In order to continue to improve the reliability and performance of the data-fetching system, we have established a partnership with a premium subgraph service provider. This provider offers advanced infrastructure and resources that we did not have access to before.
By working with this service provider, we can now take advantage of their advanced technology and expertise to ensure that our system is able to handle high traffic and usage without any interruption. This will help to improve the user experience and ensure that users always have access to accurate and up-to-date information about their orders and positions.
Moreover, this partnership also allows us to have better scalability and disaster recovery options in place which will be an added advantage. This will ensure that our users are not affected in case of any unforeseen events.
Overall, this partnership will help us to continue to improve the reliability and performance of our data-fetching system, and provide a better user experience for our users.
Our own Node for Fallback:
We have taken the additional step of deploying our own subgraph nodes on our own servers. This approach allows us to have more control over the infrastructure and resources that are used for data-fetching.
By running our own subgraph nodes, we are able to increase the throughput as needed and use a premium private Remote Procedure Call (RPC) service. This helps to ensure that the system can handle high traffic and usage without interruption, and that users always have access to accurate and up-to-date information about their orders and positions.
Furthermore, having our own subgraph nodes also provides us with a fallback option in case of any issues with the third-party service provider we are working with. This means that if there are any interruptions to the service provided by the third-party, we can quickly switch to our own subgraph nodes to ensure that users continue to have access to the information they need.
Overall, the deployment of our own subgraph nodes is an important step in increasing the reliability and performance of our data-fetching system and improving the user experience for our users.
About Dfyn
Dfyn’s vision is to become a one-stop solution for all trading-related activities. Dfyn is a fully decentralized multi-chain trading exchange that offers cross-chain swaps powered by Router Protocol.
