Recommended Architecture for Solvers
Detailed example of a solver processing an intent
Last updated
Detailed example of a solver processing an intent
Last updated
In this section, we present a proposed architecture tailored for hedger services and components. This architecture is designed for hedgers intending to hedge their positions with a broker. Each micro-service in this architecture performs a specific function. The diagram below illustrates the architecture.
Each circle in the diagram represents a distinct micro-service within the hedger system. The micro-services within containers act as backup services for one another. It is imperative to ensure maximum isolation between these micro-services, facilitating communication via message brokers like RabbitMQ and Redis. Employing a micro-service architecture offers a plethora of advantages. For instance, any malfunction in one service will minimally impact others. Moreover, modifications to any individual module will not affect others, provided there's no change in its input or output specifications. It's strongly advised to utilize separate Docker containers for each micro-service to enhance isolation and streamline resource management. This modular approach promotes superior scalability and fault tolerance. Each micro-service can scale autonomously, and a failure in one won't compromise the others. In essence, a micro-service architecture offers numerous advantages, such as enhanced isolation, scalability, fault tolerance, and efficient resource management.
A brief overview of each micro-service's function is as follows:
Hedger Web-Server: This micro-service offers the APIs and web-sockets essential for the front-end, as discussed in the preceding section. It extracts data from the Hedger database, processes it, and transmits it to the front-end.
SYMMIO Blockchain Input Module: This module's duty is to capture events from the blockchain. Given the critical nature of this information for the hedger, three separate micro-services, performing identical functions, have been established. This redundancy ensures that if one service falters, the others remain operational. These micro-services function as event-listeners, procuring a real-time stream of blockchain events via a websocket RPC. The subgraph fetcher extracts data from the subgraph, while the event poller captures events using an HTTP RPC.
Web3 Agent: This module facilitates transactions and view calls required by other micro-services.
Balance Manager: This component manages the allocation of the hedger's funds across its sub-accounts to virtually eliminate liquidation risks. For instance, if the hedger's health ratio is disparate across sub-accounts, this module will reallocate funds accordingly to maintain equilibrium.
Position Manager: Serving as the hedger's core service, the Position Manager handles pivotal actions and decisions. It processes events fetched from the blockchain and the status of pending broker positions. This module evaluates hedger policies and executes appropriate actions such as initiating or terminating positions on either the broker or contract side. Given its significance, it's advisable to deploy multiple instances of this service.
Broker Order Monitoring: This module oversees the status of limit orders with the broker and notifies the Position Manager upon order execution. Two micro-services, one relying on a WebSocket and the other on an API call, fetch these orders to ensure uninterrupted hedger availability.
Broker Order Maker: This module oversees necessary updates on the broker side, encompassing order creation, cancellation, and termination.
Position Validator: Every position is reflected across three platforms: the broker, the blockchain, and the hedger database. This module's role is to ensure uniformity across these platforms and alert developers in case of discrepancies.
Monitoring and Developer Alerts: This system monitors all micro-services, raising alerts to developers if any anomalies arise.
