[System Topology & Overview]

High-level architectural blueprint of the Hoox trading ecosystem, detailing edge microservice layouts, and multi-layered security models.

Hoox is an enterprise-grade, serverless algorithmic trading platform built entirely on Cloudflare's Edge V8 isolates and globally distributed resources. By using a modular, service-oriented architecture, Hoox decomposes complex trading processes into ten highly specialized micro-workers.

These workers communicate privately in microseconds, auto-scale globally near exchange servers, and store transaction logs in localized databases—all while running within Cloudflare's $0 free tiers.


High-Level System Architecture

The ecosystem splits public-facing ingress points from private internal compute layers:


Comprehensive Micro-Worker Catalog

Worker NameRuntime ScopeCron TriggerPublic RoutingSmart PlacementPrimary Observability
hooxGateway RouterNoYes (/webhook)Yes (Fast path)Time-series Telemetry
trade-workerOrder ExecutionNoNo (Isolated)Yes (Exchange Proxied)Execution Logs
agent-workerRisk ManagementCron */5No (Isolated)Yes (Account Auditing)Alert Logs
telegram-workerAlerts & ChatNoNo (Isolated)Yes (Telegram APIs)Command Logs
d1-workerSQLite ManagerNoNo (Isolated)Yes (SQLite Bound)Query Latency
report-workerPuppeteer PDFCron 06,18No (Isolated)Yes (Rendering APIs)Print Status
email-workerIMAP ParsingCron */5No (Isolated)NoParse Statistics
web3-walletDeFi Swap EngineNoNo (Isolated)NoTx Sign Logs
analytics-workerObservabilityNoNo (Isolated)NoMetrics Dataset

The 5-Layer Security Architecture

Security is designed as concentric protective corridors:

[ WAF: IP Range Allow-list ] -> [ Gateway: Webhook Passkey ] -> [ Isolation: Service Bindings ] -> [ Worker Auth: INTERNAL_KEY ] -> [ Mutex: Durable Objects ]

Layer 1: Edge-Level Firewall & WAF

Cloudflare's global WAF drop connections immediately at the edge if:

  • The payload does not originate from verified TradingView webhook IP ranges.
  • The request rate exceeds threshold ceilings (10 requests/minute).

Layer 2: Webhook Passkey Authentication

The hoox gateway validates that the payload apiKey string exactly matches the encrypted webhooks:api_key stored inside your CONFIG_KV namespace. Mismatched signals are instantly dropped with a 401 Unauthorized response.


Layer 3: Service Binding Encrypted Isolation

Internal workers (trade-worker, d1-worker, agent-worker) expose zero public HTTP endpoints. They cannot be targeted or accessed from the public internet. They can only be invoked internally by other V8 isolates using Cloudflare Service Bindings.


Layer 4: Standardized Internal Authorization

To prevent internal bypass or privilege escalation, all internal microservice boundaries enforce a strict bearer authorization check:

  • All internal workers (hoox, trade-worker, d1-worker, agent-worker, telegram-worker) are bound to the same INTERNAL_KEY_BINDING secret.
  • Every service-to-service invocation is audited by the shared requireInternalAuth middleware from @jango-blockchained/hoox-shared/middleware, dropping unauthorized calls.

Layer 5: Durable Object Idempotency Locks

If the network drops after an order fill, TradingView will resend the webhook. The gateway uses a single-threaded Durable Object to lock the request trace ID. If the transaction ID has already been logged, the duplicate is dropped before hitting exchange APIs, preventing double-ordering.


Tip

Smart Placement is enabled across all critical execution paths. This ensures that even though your webhook might hit a Cloudflare edge node in London, the actual transaction logic automatically shifts to Frankfurt or Tokyo (wherever the exchange APIs reside), eliminating network slippage entirely.


Codebase Dependency Graph

Hoox ships with an automated function-level dependency graph extractor that maps every exported symbol, import, call, type reference, and service binding across all 917 source files and 14 workspaces.

Generating the Graph

# From repository root
bun run graph

This runs scripts/extract-graph.ts (powered by ts-morph) and scans 917 source files across all 14 workspaces in ~20–25s.

During extraction, an 8-phase live progress bar reports each stage with timing:

  [██░░░░░░░░░░░░░░░░░░] 13%  exports: 1667 nodes             10.6s
  [██████████░░░░░░░░░░] 50%  type refs: 2536 edges            1.7s
  [████████████░░░░░░░░] 63%  calls: 445 edges                 9.7s
  [████████████████████] 100% Done                             22.0s

⏱  Total time: 22.0s
FileSizeFormatPurpose
graph.json2.5 MBJSON (997 nodes, 5536 edges)Machine-readable — AI context, programmatic queries
graph.dot1.3 MBGraphviz DOT (14 clusters)Visual rendering — workspace-clustered architecture diagram

Node Types & Color Coding (DOT)

ShapeKindExample
boxFunction / ConstexecuteTrade, CONFIG_KV
noteInterface / TypeTradeRequest, Env
componentClassIdempotencyDO
MrecordEnumExitCode, OrderStatus
Penwidth=2Entry Pointmain, export default

Entry points (top-level workspace exports) are highlighted with double borders.

Edge Color Legend

ColorEdge KindCount
Blue #4A90D9Imports2,524
Orange #FF9800Type references2,536
Pink #E91E63Cross-file calls445
Green #4CAF50Extends7
Light Green #8BC34AImplements2
Purple #673AB7Service bindings11
Cyan #00BCD4Workspace deps11

Rendering to SVG

# Requires Graphviz installed
dot -Tsvg graph.dot -o graph.svg

# Or paste graph.dot into edotor.net / viz-js.com

Key Extraction Rules

  • Export-only nodes: Only exported symbols appear in the graph (684 unexported symbols filtered out).
  • Call edge fallback: Method calls like router.post resolve via TypeChecker; when the symbol name (post) doesn't match a top-level export, the edge falls back to the target file's first container node.
  • Self-reference filtering: Calls within the same file are excluded.
  • Deduplication: Duplicate edges are collapsed into a single entry.
  • Service bindings: Parsed from each worker's wrangler.jsonc configuration.

Next Steps

Enterprise / Institutional Scale

For the full bleeding-edge Enterprise architecture (Workers for Platforms multi-tenancy, Workflows, Logpush audit, AI Gateway, Bot Management, etc.) — the commercial layer on top of the open core — see:

  • docs/enterprise/architecture.mdx
  • docs/enterprise/multi-tenancy.mdx
  • docs/enterprise/observability-audit.mdx
  • docs/enterprise/security-compliance.mdx

See also root OPEN_CORE.md and OPEN_CORE_FEATURE_SPLIT.md.

These build directly on the current retail architecture while unlocking Cloudflare Enterprise features and 2025-2026 primitives.