Architecture Overview

TRADEOS.tech is built as a microservices system connected by an event-driven Redis Streams bus. Each service has a single responsibility, communicates asynchronously, and can be deployed, scaled, or restarted independently.

Service topology

┌─────────────┐     market_data stream     ┌──────────────────┐
│  Ingestion  │ ─────────────────────────► │  Signal Engine   │
│  Service    │                            │                  │
└─────────────┘                            └────────┬─────────┘
                                                    │ signals.raw
                                                    ▼
                                           ┌──────────────────┐
                                           │ Signal Modifier  │
                                           └────────┬─────────┘
                                                    │ signals.modified
                                                    ▼
┌─────────────┐     intents stream         ┌──────────────────┐
│  TRADEOS.tech    │ ◄─────────────────────────  │   Feasibility    │
│  (API/UI)   │                            │   Service        │
└──────┬──────┘                            └──────────────────┘
       │ orders stream                              ▲
       ▼                                           │ feasibility.results
┌─────────────┐                                    │
│  Execution  │ ──────────────────────────────────►│
│  Service    │
└──────┬──────┘
       │ fills.raw
       ▼
┌─────────────┐
│ TCA Monitor │  (post-trade analysis, signal outcomes)
└─────────────┘

All inter-service communication in the trade path uses Redis Streams, not HTTP. This is a deliberate architectural choice: streams provide durability, replay capability, and natural backpressure without tight coupling between services.

---

Service descriptions

Ingestion Service

Connects to multiple exchange WebSocket feeds simultaneously (Coinbase, Kraken, Gemini, Binance) and normalizes market data into a canonical format published to the market_data Redis Stream. Also polls on-chain data (DexScreener, DefiLlama), macro data (FRED), and funding rates.

Data flows into the signal engine in real time with sub-100ms latency from exchange to signal evaluation.

Signal Engine

Consumes normalized market data and runs a battery of signal generators in parallel. Each generator produces a signal with a type classification, direction, confidence score, and supporting metadata. Signals are gated by a regime classifier before being forwarded — a momentum signal in a mean-reverting regime is suppressed before it can generate a trade intent.

The signal engine also maintains a hero signal list — the highest-performing signal types by information coefficient — which receive preferential scoring weight.

Signal Modifier

Applies meta-state adjustments to raw signals. This includes win-rate streak weighting (signals from generators with recent strong performance are boosted), information coefficient scaling, and opposing-signal suppression (conflicting signals on the same instrument cancel each other out). The result is a cleaner, higher-confidence signal stream.

Feasibility Service

This is the primary risk enforcement point. For every trade intent received, feasibility:

1. Validates that the intent passes all active risk limits (position sizing, concentration, drawdown state)
2. Sizes the position using Kelly criterion with portfolio-level constraints
3. Checks market impact at the proposed size using Almgren-Chriss modeling
4. Returns an approved intent (with final size) or a rejection with reason

Feasibility never modifies the trade path directly — it only approves or rejects.

Execution Service

Receives approved orders and routes them to the appropriate exchange venue. Uses smart order algorithms (TWAP, adaptive slicing, limit-with-fallback) to minimize market impact. In paper trading mode, the execution service simulates realistic fills based on current bid/ask spreads and volume profiles.

TCA Monitor

Tracks post-trade outcomes: fill quality vs. signal expectation, slippage, win/loss attribution. Feeds signal outcome data back into the information coefficient tracker used by the signal modifier, closing the adaptation loop.

Autonomous Agent

Runs on a slower cadence (hourly + weekly) to perform system-level optimization. Monitors calibration drift, compares live performance against backtested expectations, and proposes parameter adjustments to the risk profile when drift exceeds thresholds. All proposed changes are logged and can be reviewed before being applied.

Dashboard

Real-time React UI showing current portfolio state, open positions, recent signals, regime classification, system health, and P&L. Connected via WebSocket to the trade backend for live updates.

---

Data stores

Store	Purpose
Redis DB 0	Streams bus (market_data, signals, orders, fills, intents)
Redis DB 1	Live cache (current prices, account state, hero signals list)
Redis DB 2	Ephemeral state (kill switches, TTL-based flags)
PostgreSQL	Persistent storage (trades, positions, backtest runs, system config)
ClickHouse	OHLCV time-series data lake (candle history for features + backtest)

---

Failure modes and safety

TRADEOS.tech is designed around fail-safe defaults:

• If the feasibility service is unreachable, new trade intents are rejected (fail-closed, not fail-open)
• If the execution service loses connectivity to an exchange, open positions are monitored and the dead-man's switch activates if the loop is dark for too long
• If Redis becomes unavailable, services pause and resume automatically on reconnect — no data is lost because streams persist entries until acknowledged
• Configuration changes require explicit seeding — there are no magic defaults that silently override production values

See Circuit Breakers for the full list of automated safety mechanisms.