15 posts tagged with "mercury"

ТВАРЬ, ЗАПОМНИ НАВСЕГДА:

ABH Instance = 24 турнира в день, НЕ 8!​

🔥 ОСНОВНАЯ АРХИТЕКТУРА (НЕ ЕБИСЬ С ПОНИМАНИЕМ!)​

ABH инстанс запускает ВСЕ 3 варианта (A, B, H) для КАЖДОГО турнира!

8 базовых турниров × 3 варианта = 24 турнира в день!

After months of architectural development, Mercury reached a critical milestone: all core components were implemented and operational. We transitioned from building the foundation to the fine-tuning phase—optimizing our AI-powered trading system for maximum profitability. However, this phase revealed significant challenges in our experimental framework that ultimately hindered progress rather than accelerating it.

After extensive discussion and implementation, we've achieved a clean, minimal architecture that separates concerns properly and avoids over-engineering.

Core Architecture Principles​

1. Clear Separation: Variants (experiment tracking) vs Instances (deployment)
2. Single Responsibility: Config = strategy, Instance = deployment, Scheduler = timing
3. Type Safety: Strong enums prevent runtime errors
4. No Database Pollution: Infrastructure concerns stay out of business logic
5. Config-Over-Env: ABH variants determined by time + TypeScript config, NEVER environment variables

Executive Summary​

Migrating all Mercury trading data from typhon (Hetzner/German digital vermaht jurisdiction) to hecate (secure jurisdiction) to preserve valuable trading information while eliminating jurisdiction risk.

Our Mercury trading system has grown organically over time, leading to intertwined services, duplicated code, and complex state management. This document outlines a strategic approach to refactoring key components to improve maintainability, testability, and performance.