How signals enter the HOOX mesh — validation, normalization, rate limiting, and idempotency at the edge.
Every trading system has a front door. In HOOX, that front door is a Cloudflare Worker called "hoox" — a gateway that does one thing and does it well: validate, route, and forget. No state, no database, no caching layer between the wire and the execution engine. The entire signal path from TradingView webhook to exchange order is a straight line through nine V8 isolates, and the first one sets the tone.
Ingress design is the single most underestimated surface in algorithmic trading. Most systems treat it as a simple HTTP handler — parse the body, push to a queue, move on. HOOX treats it as the security perimeter of a cryptographic protocol. Every signal carries an authenticated identity. Every webhook is signature-verified at the TLS termination layer before it reaches application code. The system does not trust the network; it trusts the key.
The hoox gateway validates TradingView webhook signatures using HMAC-SHA256 with per-strategy secrets stored in CONFIG_KV. It enforces IP allowlists, rate-limits by origin and endpoint, and strips every header that is not explicitly required downstream. The result is a sanitized, attested payload — a cryptographically wrapped order intent that can be forwarded to trade-worker with zero additional validation at the recipient.
But ingress is not just security. It is also the contract between the signal source and the execution mesh. TradingView webhooks carry a fixed JSON schema. Email signals from Mailgun arrive as multipart MIME. Telegram bot commands arrive as Update objects. The hoox gateway normalizes each format into a canonical HooxSignal — a typed, validated, idempotency-keyed structure that every downstream worker understands. The normalization happens at the edge, not in a central service, because the edge is where the source lives.
Rate limiting at ingress is not a polite throttle. It is a circuit breaker. Each strategy has a configurable maximum signal rate. If the rate is exceeded, the gateway returns HTTP 429 and logs the overflow to Analytics Engine. The strategy is not blocked — it is debited. The rate limit is enforced per origin, per strategy, and globally. Three independent budgets, any of which can trip the breaker.
The ingress layer also owns the idempotency handshake. Every HooxSignal carries a unique key derived from the source's own sequence identifier. Before the signal is forwarded to trade-worker, the gateway performs a lookup against the IdempotencyStore Durable Object. If the key exists, the signal is a replay — return HTTP 200 (not 409, because the original succeeded) and discard. If the key is new, proceed. This handshake adds ~3ms to the critical path and eliminates the entire class of double-execution bugs that plague TradingView webhook integrations.
What does not belong at ingress? Business logic. Position sizing, risk assessment, exchange selection — these are downstream concerns. The gateway does not know what a "long" or "short" is. It does not know which exchange will receive the order. It knows only: is this signal authentic? Is it within rate? Is it a duplicate? If the answer to all three is no, forward. This separation of concerns is what allows the execution layer to be replaced, reconfiguring zero lines of gateway code.
Ingress in HOOX is the narrow waist of the system. A well-defined surface area, cryptographically bounded, rate-limited by three independent budgets, and normalized into a single canonical type. Every signal enters the mesh through the same narrow aperture. What happens on the other side is the concern of ten other workers, each with a single responsibility, none of which trust the network or each other.
Deployed as a single Cloudflare Worker at the edge in 40+ locations. The hoox worker is the only publicly-routed endpoint in the entire mesh. Its entire addressable surface is three routes: POST /webhook/tradingview, POST /webhook/telegram, and POST /api/email. Every other worker in the system is internal — reachable only through Service Bindings, never through the public internet.
This topology is not incidental. It is the direct consequence of a design constraint: no internal worker should ever see an unauthenticated request. By funneling all external traffic through a single validated ingress, the system reduces the trusted computing base to exactly one worker that parses untrusted input. Every other worker operates on pre-validated, pre-normalized signals.
Each signal source speaks a different protocol. TradingView sends JSON with a specific schema. Telegram sends Update objects with message text. Email arrives as MIME with attachments. The hoox gateway translates each into an internal HooxSignal type carrying: strategy id, action (buy/sell/close), instrument, quantity or percentage, optional price limit, source metadata, and the idempotency key.
The normalization pipeline is a chain of pure functions — parse, validate, transform, attest. Each step is independently testable. The pipeline rejects malformed signals with a structured error response before any downstream worker is invoked. This means trade-worker never parses raw JSON. It receives a HooxSignal and executes.
Because ingress runs at the Cloudflare edge, signal validation happens in the data center closest to the sender. A TradingView webhook originating in São Paulo is validated in São Paulo — not routed to a central region, validated, and then forwarded. This reduces the already-submillisecond validation latency to a single digit: the time it takes to compute an HMAC and check three counters.
The same edge distribution applies to rate limiting. Each edge location maintains an in-memory counter per strategy per origin. Counters are periodically written to CONFIG_KV for global visibility but are never read from KV on the hot path. The hot path is in-memory only. This means rate limit enforcement is eventual across regions but instantaneous within a region — a deliberate tradeoff that prioritizes latency over global consistency. In practice, a strategy flooding from a single region is caught within three requests.