Platform Architecture

What runs under the hood

ManySignal is a pipeline of specialized services: a structured ingestion layer, a temporal entity graph, a streaming detection engine, a multi-model AI orchestration layer, and a governed action runtime. Each layer has a well-defined contract with the next.

Book a technical deep-dive Read the API docs

Pipeline layers

Layer 1: Ingestion

Connector workers (REST, Kafka, syslog, S3)Schema validation and field normalizationIdempotency dedup using deterministic event keysDead-letter queue with replay capabilitySilent connector watchdog

Layer 2: Entity graph

Entity resolution and deduplication across sourcesTemporal edge storage with 180-day historyBehavioural baseline computation (per-entity rolling profiles)Blast radius pre-computation for critical entity nodesGraph query API used by detection and AI layers

Layer 3: Detection

Streaming, threshold, and sequence rule evaluationRule compilation to optimized evaluation graphAlert-only and active mode per ruleFinding deduplication by entity and windowMITRE annotation at rule level

Layer 4: AI orchestration

Multi-model routing per task type (classification, reasoning, NLP, code)Typed evidence gathering per question setWeighted verdict synthesis with reasoning traceContext bundle assembly from entity graph + finding + intelModel output validation against typed verdict schema

Layer 5: Case and response

Case creation with pre-populated entity snapshotWorkflow engine (Temporal-based DAG execution)Guardrail evaluation at action execution layerRollback state recording for reversible actionsFull audit trail with hash-chained integrity

Technology choices

Ingestion Go worker processes with Kafka-compatible consumer protocol

Event store ClickHouse for hot tier (sub-second aggregation queries); Parquet on S3-compatible object storage for cold tier

Entity graph Apache AGE (PostgreSQL extension) for embedded deployments; Amazon Neptune for large-scale cloud deployments

Workflow engine Temporal.io for durable, stateful workflow execution across failure scenarios

API server Single Go binary serving REST and GraphQL. gRPC internal service communication.

AI inference vLLM-compatible inference server; adapters for OpenAI, Anthropic, Azure OpenAI, and Bedrock APIs

Frontend React SPA served as static assets; WebSocket-based live alert stream

Architecture — FAQ

What is the minimum deployment footprint?

A non-HA single-tenant deployment runs on 3 Kubernetes nodes with 8 cores and 32 GB RAM each. Production deployments across 3 availability zones require 9+ nodes. Sizing guidance for specific event volumes is in the operator documentation.

How are updates applied without downtime?

Each service is deployed as a Kubernetes Deployment with a RollingUpdate strategy. The platform maintains backward compatibility between component versions within a minor release series, so rolling updates do not require a coordinated shutdown.

What is the event processing throughput ceiling?

The ingestion layer scales horizontally by adding connector worker replicas. Internal testing has processed 2 million events per second on a 20-node cluster before hitting event-store write throughput limits. ClickHouse write throughput is the typical bottleneck for large deployments.

Does ManySignal have a service mesh dependency?

No. The platform is deployable without a service mesh. Internal service communication uses mTLS with certificates managed by cert-manager. If your cluster runs Istio or Linkerd, the platform is compatible but does not require them.

What databases and storage engines does the platform use?

The event store uses ClickHouse for high-throughput append and analytical queries. The entity graph runs on a custom graph engine backed by PostgreSQL for state and Redis for hot-path lookups. Object storage (S3 or S3-compatible) holds raw event archives and evidence attachments.

How is tenant isolation enforced at the architecture level?

Each tenant's data is partitioned in ClickHouse by tenant ID with row-level access control enforced in the query layer. The API gateway validates tenant context on every request before it reaches a data store. Cross-tenant data access is architecturally blocked, not just policy-controlled.

Can we run the platform in an air-gapped environment?

Yes. Self-hosted deployments support air-gapped operation: all container images are available as a signed tarball bundle, threat intelligence feeds can be loaded from an internal mirror, and AI model inference can run on a locally hosted model endpoint.

What does the disaster recovery architecture look like?

Cloud-hosted deployments run across three availability zones with continuous replication. RPO is under 5 minutes and RTO under 30 minutes for the cloud-hosted tier. Self-hosted customers configure their own DR posture; the operator documentation includes reference architectures for cross-region failover.

How does the platform handle secrets and API credentials for connectors?

All connector credentials are stored in HashiCorp Vault with 90-day automatic rotation. Secrets are never written to application logs or audit trails. Connector manifests reference secret paths, not values — the worker fetches credentials at connection time from Vault.

Built to be understood, not just trusted

Request a technical deep-dive with the engineering team — architecture, scaling, and integration questions welcome.

Book a demo Explore the platform