Skip to main content

60. Three-Tier Instance Architecture

Status: Accepted Date: 2025-07-06

Context​

A trading system requires different environments for different purposes: live execution, safe testing of changes, and aggressive data collection for research. Previously, our instance strategy was ambiguous, with "demo" instances performing shadow simulation instead of true validation. This led to confusion and a gap in our ability to safely validate strategies and gather complete market intelligence.

Decision​

We will formally adopt a Three-Tier Instance Architecture. The system will be deployed in three distinct configurations, or "instance types," each with a non-overlapping, clearly defined purpose:

  1. W (Live/Writer) Instance: This is the production instance that trades with real funds. It operates under conservative risk management rules and its exposure is controlled by a liveRatio parameter. This is the only instance that holds live API keys.
  2. R (Demo/Reader) Instance: This instance is a perfect mirror of the W instance's configuration, logic, and risk constraints. However, it connects exclusively to the exchange's demo/testnet API. Its sole purpose is to validate the behavior and performance of a strategy in a realistic, but risk-free, environment.
  3. ABH (Intelligence/Hypothesis) Instance: This instance is for pure market intelligence gathering. It runs the same strategies as W and R but disables all risk management filters. Its job is to capture the data on every potential trade the strategies identify, creating a rich, unfiltered dataset for offline analysis and model optimization. It does not execute trades.

Consequences​

Positive:

  • Clarity of Purpose: Eliminates ambiguity. Everyone knows exactly what each instance type is for.
  • Robust Validation Pipeline: Creates a clear workflow for promoting strategies: a model is first analyzed on data from ABH, then validated for behavior on R, and finally deployed to W.
  • Complete Market Intelligence: The ABH instance provides a priceless dataset of "what could have been," which is impossible to get from live or filtered demo trading. This is a significant competitive advantage for strategy research.
  • Enhanced Safety: The strict separation of concerns, especially keeping live keys only on the W instance (adr://hardware-isolation), drastically reduces the risk of accidental real-money trades.

Negative:

  • Increased Infrastructure Cost: We need to run and maintain three separate types of instances, which increases infrastructure and operational costs.
  • Configuration Management Complexity: We must ensure that the configuration between W and R instances stays perfectly synchronized, which requires disciplined configuration management.

Mitigation:

  • Shared Configuration: The W and R instances will source their logic and risk rules from the exact same version-controlled configuration files. The only difference will be in their environment variables (e.g., API keys, database connection strings).
  • Automated Deployment: Our Ansible and Docker configurations will manage the deployment of all three instance types, ensuring consistency and reducing manual effort.
  • Cost is an Investment: The additional infrastructure cost is considered a strategic investment in safety and superior market intelligence, which are essential for a successful trading operation.