Redundant Match Engine Architecture for Deterministic Financial Trading
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current electronic trading systems face challenges in maintaining transactional determinism, fault tolerance, and equitable access to information under increasing loads, with high performance requirements and the need for improved risk management and market protection mechanisms.
Innovation Solution
The implementation of a redundant match engine architecture with an Orderer component for deterministic transaction sequencing and a Decider component for result arbitration, combined with FPGA-based processing to enhance performance and fault tolerance, and the provision of customized market data feeds and credit evaluation mechanisms.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a single match engine is used to process transactions, then device complexity is low, but reliability deteriorates under increasing loads and fault conditions
Solution Approach 1:
The match engine is segmented into multiple independent instances (first match engine, second match engine, third match engine) that can operate in parallel. Each match engine processes a subset of transactions, distributing the computational load and eliminating single points of failure. The segmentation allows the system to maintain reliability even if individual match engines fail.
Solution Approach 2:
The system implements predetermined failover mechanisms where backup match engines are pre-configured and ready to take over if primary match engines fail. The load balancer is pre-programmed with health check routines and automatic redirection logic, providing cushioning against faults before they impact system reliability.
2Reliability
If multiple match engines are implemented for fault tolerance, then reliability improves, but transactional determinism deteriorates due to coordination overhead
Solution Approach 1:
The load balancer performs preliminary actions by pre-establishing health check routines and failover protocols before faults occur. It continuously monitors match engine status and maintains an updated mapping of healthy engines, enabling immediate deterministic routing decisions without coordination overhead during transaction processing.
Solution Approach 2:
The load balancer serves as an intermediary that abstracts the complexity of multiple match engines from the transaction processing logic. It deterministically routes transactions to healthy match engines using pre-established rules, eliminating the need for complex inter-engine coordination while maintaining transactional determinism.
3Productivity
If transaction volume is increased to improve productivity, then throughput improves, but transactional determinism deteriorates due to system complexity
Solution Approach 1:
The system segments the transaction processing workload across multiple match engines, with each engine handling a specific subset of transactions. This segmentation enables parallel processing that increases throughput while maintaining deterministic behavior within each segment, as each match engine independently processes its assigned transactions without coordination overhead.
Solution Approach 2:
The load balancer acts as an intermediary that maintains transactional determinism by implementing a deterministic routing strategy. It distributes incoming transactions to match engines using predefined rules (such as round-robin or hash-based distribution), ensuring that the same transaction always routes to the same engine, thereby preserving determinism even as total throughput increases.
4Reliability
If health check routines are implemented frequently to monitor match engine status, then reliability improves, but processing speed deteriorates due to overhead
Solution Approach 1:
The load balancer implements periodic health check routines that operate independently of transaction processing. By using periodic polling at predetermined intervals rather than continuous monitoring, the system maintains reliable fault detection while minimizing overhead that would otherwise slow down transaction processing. The periodic action separates monitoring concerns from critical transaction paths.
Data Source
AI summary
The disclosed embodiments relate to implementation of a trading system, which may also be referred to as a trading system architecture, having improved performance which further assures transactional determinism under increasing processing transaction loads while providing improved trading opportunities, fault tolerance, low latency processing, high volume capacity, risk mitigation and market protections with minimal impact, as well as improved and equitable access to information and opportunities.