330348e84d
The update_position method previously acquired a read lock to get the Arc<AtomicPosition>, dropped it, then called update_with_execution outside any lock. Two concurrent fills for the same position could both load the same old_quantity via Acquire, compute independent new quantities, and the last Release store would silently discard the other fill — causing the position to show e.g. 10 shares when it should show 20. Now holds the positions write lock across the entire get-or-create + update_with_execution sequence, serializing concurrent fills per position. The validate_position_update call remains outside the lock to minimize hold time (it does its own async reads and risk checks). Also removes excessive per-step RDTSC latency tracking from the critical path (total latency tracking is preserved) and adds a multi-threaded regression test that spawns 10 concurrent +1 fills and asserts the final quantity equals 10. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Trading Service
Overview
The trading_service is the core execution engine for the Foxhunt HFT platform. It manages the entire lifecycle of trading operations, from order placement and execution to real-time position keeping and risk management. This service is critical for high-frequency, low-latency trading activities, ensuring compliance and optimal performance.
Features
- Order Execution: Handles high-throughput order placement, modification, and cancellation across various exchanges.
- Position Management: Maintains real-time tracking of all open positions, including P&L calculations and exposure.
- Risk Integration: Integrates with upstream risk systems to enforce pre-trade and post-trade compliance checks.
- Compliance Checks: Automatically applies regulatory and internal compliance rules to all trading activities.
- Market Data Subscriptions: Subscribes to and processes real-time market data feeds for informed decision-making.
- Real-time P&L Tracking: Provides immediate profit and loss updates for active strategies and overall portfolio.
- Health Checks and Metrics: Exposes endpoints for monitoring service health and operational metrics.
gRPC API
The trading_service exposes a gRPC API for interacting with its core functionalities. Key endpoints include:
PlaceOrder- Submit new ordersCancelOrder- Cancel existing ordersGetPosition- Query current positionsSubscribeMarketData- Subscribe to market data feedsGetPnlUpdates- Retrieve real-time P&L updates
Running the service
To run the trading_service binary:
cargo run --bin trading_service
Configuration
The service is configured via the central config crate with PostgreSQL backend. Key configuration includes:
- Database connection strings
- Risk parameters and limits
- Broker connection settings
- gRPC server port and TLS settings
TLS Configuration (Agent S3)
The Trading Service supports TLS 1.3 with optional mutual TLS (mTLS) for secure gRPC communications.
Environment Variables:
TLS_ENABLED=false # Enable TLS (default: false)
TLS_CERT_PATH=/app/certs/trading_service/server.crt # Server certificate
TLS_KEY_PATH=/app/certs/trading_service/server.key # Server private key
TLS_CA_PATH=/app/certs/trading_service/ca.crt # CA certificate
TLS_REQUIRE_CLIENT_CERT=false # Require client certs (default: false)
Certificate Directory Structure:
/app/certs/trading_service/
├── server.crt # Server certificate
├── server.key # Server private key
└── ca.crt # CA certificate for client verification
Features:
- TLS 1.3 encryption for all gRPC traffic
- Mutual TLS (mTLS) support for client certificate authentication
- 6-layer certificate validation (expiration, purpose, constraints, extensions, SANs, revocation)
- Role-based access control (RBAC) via certificate Organizational Unit (OU)
- CRL (Certificate Revocation List) support
Security Note: TLS is disabled by default for development. Enable TLS_ENABLED=true for production deployments.
Testing
To run the tests for the trading_service crate:
cargo test --package trading_service
Documentation
Comprehensive API documentation is available at docs.rs/trading_service.