Architecture

Edge is a lightweight Zig proxy that applies policies to telemetry at high throughput and low latency.

​

Component Overview

​

Internal Architecture

​

Protocol Modules

Each distribution includes modules for specific protocols: Modules are stateless. They parse incoming requests, evaluate policies, and forward results. All state lives in the policy registry.

​

Policy Registry

The registry holds all loaded policies and provides lock-free read access during request processing. Key properties:

• Atomic snapshots: Writers create new snapshots; readers use existing ones
• Lock-free reads: No contention during policy evaluation
• Hot reload: New policies take effect without restart

Policy updates do not block request processing.

​

Policy Engine

The engine evaluates policies against telemetry using Vectorscan (a Hyperscan fork) for regex matching. Evaluation flow:

1. Index lookup: Find policies that might match based on field keys
2. Regex scan: Evaluate regex patterns against field values
3. Action merge: Combine keep/transform actions from matching policies
4. Apply: Execute the merged actions

Vectorscan compiles regex patterns into finite automata, enabling simultaneous evaluation of thousands of patterns in a single pass.

​

Policy Providers

Providers load policies from external sources: Multiple sources can be configured. Policies from all sources merge together. The policy ID acts as a unique key. If two providers emit a policy with the same ID, the one from the higher-priority source (HTTP > file) wins. Same-priority sources will have the later update win. This structure allows you to create a set of default policies that can be overridden remotely.

​

Design Principles

​

Data-Oriented Design

Edge optimizes for memory access patterns and cache coherency. It lays out data structures for sequential access to minimize cache misses during high-throughput processing.

​

Lock-Free Reads

Policy evaluation reads policies on each request, while updates stay rare. Edge uses atomic pointers to policy snapshots, eliminating read-side synchronization.

​

Fail-Open

Edge prioritizes availability. If policy evaluation fails, Edge forwards the telemetry unchanged. A filter may not apply, and no data is dropped.

​

Stateless Modules

Protocol modules are stateless. Each module:

1. Parses the request
2. Reads policies from the registry
3. Applies policies to the data
4. Forwards to upstream

Engineers can inspect each module in isolation, and Edge can run modules in parallel.

​

Performance Characteristics

Performance depends on:

• Number of regex patterns (more patterns = more evaluation time)
• Request body size (larger bodies take longer to parse)

​

Deployment Patterns

​

Gateway

Deploy Edge as a shared gateway for multiple services: Use Case: Tero Edge sits at the egress point after your telemetry pipeline. It acts as a final gateway before data leaves your network and applies cost-focused policies that reduce egress to SaaS vendors. Drop redundant health checks and sample high-cardinality metrics before your provider bills for them. Best for:

• Centralized policy management
• Environments with many services
• When you want a single point of control

​

Sidecar

Deploy Edge alongside each service: Use Case: Tero Edge runs as a lightweight sidecar next to each application. It applies policies at the source by dropping noisy debug logs, redacting PII, or sampling high-volume metrics before data reaches the telemetry pipeline. This reduces load on collectors and network bandwidth within your infrastructure. Best for:

• Service-specific policies
• Isolation between services
• Kubernetes environments with sidecar injection

​

Next Steps