Multi-Service Design
NeuraTrade follows a service-oriented architecture with three core services:backend-api
Go API server with domain logic, persistence, and autonomous orchestration
ccxt-service
Bun + CCXT exchange bridge for unified exchange access
telegram-service
Bun + grammY bot for notifications and operator interaction
Design Philosophy
Go for Performance: Backend API leverages Go’s concurrency model for high-throughput market data processing and real-time arbitrage detection.
TypeScript for Ecosystem: Sidecar services use Bun + TypeScript to leverage mature exchange (CCXT) and bot (grammY) libraries.
Technology Stack
Core Components
| Component | Technology | Purpose |
|---|---|---|
| Backend API | Go 1.26+ | Trading logic, arbitrage engines, AI agents, API |
| CCXT Service | Bun + CCXT | Exchange communication and order execution |
| Telegram Service | Bun + grammY | Bot commands and notification delivery |
| Database | SQLite | Persistent storage for trades, signals, positions |
| Cache | Redis | Real-time state, distributed locks, queues |
Native-First Deployment
NeuraTrade is designed for native binary deployment without container dependencies:Process Management
Theneuratrade CLI orchestrates all services:
- Single Gateway: One command to start/stop all services
- Process Monitoring: Health checks and automatic restarts
- Native PIDs: Services run as native OS processes
- Runtime State: Stored in
NEURATRADE_HOME(default:~/.neuratrade)
Data Flow Overview
See Data Flow for detailed pipeline documentation.
Service Communication
Services communicate via multiple protocols optimized for their use cases:HTTP/REST
- Backend API → CCXT Service (exchange operations)
- Backend API → Telegram Service (notifications)
- External clients → Backend API (public API)
gRPC
- Backend API ↔ Telegram Service (delivery hooks)
- Backend API ↔ CCXT Service (streaming data)
Redis PubSub
- Quest triggers and events
- Real-time position updates
- Emergency kill switch
Service Architecture
Detailed service design and communication patterns
Quest Engine
Autonomous scheduling and quest orchestration
Key Architectural Decisions
Why Go for the backend?
Why Go for the backend?
Go provides:
- Concurrency: Goroutines for parallel market data collection
- Performance: Sub-millisecond arbitrage detection
- Type Safety: Decimal types for money math (no float errors)
- Deployment: Single binary with no runtime dependencies
Why Bun/TypeScript for sidecars?
Why Bun/TypeScript for sidecars?
Bun + TypeScript offers:
- Ecosystem: Mature CCXT library for 100+ exchanges
- Bot Framework: grammY for Telegram integration
- Fast Startup: Bun’s performance for sidecar services
- Type Safety: TypeScript for API contracts
Why SQLite instead of PostgreSQL?
Why SQLite instead of PostgreSQL?
SQLite is the default runtime database because:
- Zero Config: No separate database server to manage
- Single File: Easy backup and migration
- Performance: Fast for read-heavy workloads
- ACID: Full transactional support
PostgreSQL is supported for production deployments requiring multi-instance scaling.
Why Redis?
Why Redis?
Redis provides:
- Distributed Locks: Quest coordination across instances
- PubSub: Real-time event streaming
- Caching: Market data and API response caching
- Queues: Asynchronous job processing
Next Steps
Services
Deep dive into each service’s responsibilities
Data Flow
Complete data processing pipeline
Quest Engine
Autonomous scheduling and execution
AI Agents
Multi-agent decision system