Comparative Audit: TMC vs. UBDCC

This document provides a comprehensive analysis and audit of the Tardis Management Cluster (TMC) design compared to the existing Unicorn Binance Depth Cache Cluster (UBDCC) infrastructure.

1. Architectural Maturity & Philosophy

Attribute	UBDCC (Current)	TMC (Target Design)	Audit Note
Philosophy	"Deep & Narrow" (Binance Focused)	"Broad & Unified" (Multi-Exchange)	TMC inherits UBDCC's distributed maturity while expanding scope.
Design Pattern	Master-Worker-Proxy (Python/Cython)	Master-Worker-Proxy (Node.js/TS)	TMC adopts the same proven pattern but aligns with the Tardis ecosystem.
Control Plane	Python `mgmt` node	Node.js `master` node	Both use in-memory thread-safe state stores with replication.
Data Plane	`unicorn-binance-local-depth-cache`	`tardis-machine`	TMC leverages a more feature-rich, multi-exchange engine.

2. Data Integrity & Reconstruction

2.1 UBDCC (Institutional Standard for Binance)

Strengths: Implements strict sequence ID validation (u == prev_U + 1). Any gap triggers an immediate hard-reset of the cache.
Audit: Highly reliable for Binance. Its native integration with the Binance protocol ensures zero drift.

2.2 TMC (The Institutional Evolution)

Strengths: Normalized schema across 30+ exchanges. Built-in compression and caching for historical replay.
Gaps (Fixed in TMC Design): Standard Tardis setups lack active drift detection. The TMC design "fills" this by adding the Consistency Validation Layer (Periodic REST snapshot audit), bringing it up to UBDCC's institutional standard.
Audit: By porting UBDCC's "Sequence Gap" and "Drift Detection" logic into the Tardis engine, TMC achieves parity in data integrity while supporting a much broader market.

3. Scalability & Performance

3.1 Scaling Strategy

UBDCC: Scales by spawning multiple DCN pods (one per core). Orchestration is K8s-native but Python-bound (GIL).
TMC: Scales by spawning multiple Worker pods managing tardis-machine. Node.js's non-blocking I/O is ideally suited for high-throughput WS proxying.
Audit: TMC's "Resource-Weighted" distribution (Event Loop Lag metrics) is a more modern approach to rebalancing than UBDCC's "Unused Longest" strategy.

3.2 Throughput

UBDCC: Cython-compiled modules provide high performance for Binance data.
TMC: tardis-machine is a highly optimized C++/JS engine capable of 100k+ msg/s.
Audit: TMC is expected to outperform UBDCC in multi-exchange scenarios due to the underlying engine's optimizations for high-density historical and real-time streams.

4. Fault Tolerance & Self-Healing

4.1 State Resilience

UBDCC: Database is replicated to all nodes. On Master failure, any node can provide the state.
TMC: Adopts the Circular Backup protocol from UBDCC. The ClusterDB is replicated to all TMC-Worker nodes.
Audit: Parity achieved. TMC's "Master Recovery" logic is a direct port of UBDCC's successful self-healing mechanism.

4.2 Failover Path

UBDCC: Proxy retries different DCNs for the same market.
TMC: Gateway implements Hot-Standby Redundancy (First-to-Arrive signals).
Audit: TMC's failover logic is more advanced for trading, focusing on signal latency (picking the fastest stream) rather than just availability.

5. Use Case Suitability

Use Case	UBDCC	TMC
Live Binance Trading	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐
Multi-Exchange Research	❌	⭐⭐⭐⭐⭐
Historical Replay	❌	⭐⭐⭐⭐⭐
Ultra-Low Latency Streams	⭐⭐⭐⭐	⭐⭐⭐⭐⭐
Institutional Resilience	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐

6. Final Audit Conclusion

The TMC design is a successful institutional evolution of the UBDCC project. It preserves the distributed orchestration and self-healing reliability of UBDCC while leveraging the Tardis ecosystem to provide:

Multi-exchange support (30+ vs 1).
Unified Historical/Real-time access (Full parity for backtesting).
Modernized Scaling (Event Loop metrics vs process-based).
Enhanced Signal Integrity (Active auditing vs passive consumption).

Recommendation: Proceed with TMC implementation as it represents a significant upgrade in both capability and performance for institutional quant operations.

TMC: Institutional Architecture & Implementation Master Plan

1. Executive Summary & Rationale

The Tardis Management Cluster (TMC) is an institutional-grade evolution of the Tardis ecosystem. It applies distributed systems patterns—originally proven in the UBDCC project—to tardis-machine and tardis-node, enabling a globally scalable, high-fidelity market data infrastructure.

1.1 The Motivation

Standard exchange REST and Archive APIs present significant hurdles for institutional quant research and live trading:

Rate Limit Constraints: Fetching granular historical data via REST is throttled by weight-based limits, leading to latency and IP bans.
Archive Fragmentation: Each exchange has a unique, often proprietary archive format.
State Reconstruction Gap: Archives typically lack the initial L2 snapshots required to bootstrap an order book.

TMC solves these by:

Transparent Local Caching: Fetching data once and serving it infinitely from local NVMe storage.
Unified Normalization: Providing a single schema across 30+ exchanges.
Autonomous State Management: Automating the "Snapshot + Incremental" reconstruction logic for both historical and live feeds.

2. Requirements

2.1 Functional

Multi-Exchange Ingestion: Support for all Tardis-integrated exchanges (30+).
Distributed Master-Worker Orchestration: Automated registry, symbol assignment, and health monitoring.
High-Fidelity Reconstruction: Real-time L2 books with Active Drift Detection.
Unified WebSocket/REST Gateway: Single entry point with intelligent subscription routing.
Live Feed Collection: Low-latency data collection and broadcast to trading bots.

2.2 Non-Functional

Horizontal Scalability: Seamless addition of worker nodes to handle thousands of markets.
Master State Resilience: Master DB recovery from worker-replicated backups (Self-Healing).
Sub-millisecond Latency: Optimized data paths for live trading signals.

3. System Architecture: Master-Worker-Proxy

TMC utilizes a clean separation between the Control Plane and the Data Plane.

3.1 Component Breakdown

TMC-Master (Control Plane): The cluster "Brain." Manages the ClusterDB (registry, assignments, health).
TMC-Worker (Management Layer): A wrapper that manages a local instance of tardis-machine. It handles lifecycle, configuration bridging, and background audits.
tardis-machine (Data Engine): The high-performance engine inside the worker that performs the actual data ingestion, caching, and book reconstruction.
TMC-Gateway (Data Gateway): A high-performance router (Node.js or Nginx) that routes client requests to the correct worker node.

3.2 High-Level Diagram

graph TD
    Client[Trading Bot / Researcher] --> Gateway[TMC-Gateway]
    Gateway -->|Discovery| Master[TMC-Master]
    Master -->|Orchestration| Worker1[TMC-Worker 1]
    Master -->|Orchestration| Worker2[TMC-Worker 2]
    
    subgraph "TMC-Worker Node"
        Worker1 -->|Manage| TM1[tardis-machine]
        TM1 -->|Ingest| Exchange[Exchanges]
    end

    Worker1 -.->|DB Replication| Master
    Worker2 -.->|DB Replication| Master

4. Detailed Flows

4.1 Orchestration & Registration

Registration: A new worker starts and reports its Load Metrics (Event Loop Lag, Memory) to the Master.
Assignment: Master assigns symbols based on a Resource-Weighted Round Robin strategy.
Configuration: Worker dynamically updates the tardis-machine configuration to begin tracking the assigned markets.

4.2 The Consistency Layer (Filling the Gaps)

TMC adds an institutional validation layer missing from standard Tardis setups:

Gap Detection: Continuous monitoring of message sequence IDs (seq == last_seq + 1).
Snapshot Reconciliation: Every 5–15 minutes, the worker audits the local cache by fetching a fresh REST snapshot and comparing the Top 20 levels.
Automated Recovery: Immediate resync (Purge -> Snapshot -> Replay) if any drift is detected.

4.3 Real-time Trading Streams

Zero-Copy Routing: The Gateway establishes back-to-back WebSocket connections to workers, piping live data directly to clients to minimize latency.
Hot-Standby Redundancy: Mission-critical symbols can be assigned to multiple workers; the Gateway forwards the fastest signal to the bot.

5. Implementation Roadmap

Phase 1: Cluster Skeleton

Implement TMC-Shared (replicated state DB).
Build the Master-Worker heartbeat and registration protocol.
Implement basic "Round Robin" symbol assignment.

Phase 2: Data Plane Integration

Build the LifecycleManager to wrap tardis-machine.
Implement the configuration bridge (propagating Master assignments to tardis-machine).
Critical Task: Implement the ConsistencyValidator (Active Drift Detection).

Phase 3: Access & Self-Healing

Build the TMC-Gateway with intelligent routing.
Implement Master State Recovery (Master pulls DB from workers on startup).
Add failover logic to the Gateway.

Phase 4: Production Polish

Implement Resource-Weighted distribution (using Event Loop Lag metrics).
Build a health-monitoring dashboard.
Optimize the zero-copy WebSocket proxy path.

6. Audit & Review Notes

Consolidation: This document replaces all previous requirements and spec artifacts.
Gap Resolution: The design explicitly addresses the lack of drift detection in standard tardis-node setups.
Institutional Alignment: The architecture is optimized for both Historical Research (speed and caching) and Live Trading (latency and redundancy).

tommy-ca/ComparativeAudit.md

Select an option

No results found