Operate

Scaling

Fidacy scales horizontally with the audit and trust guarantees intact. The hot path is a handful of indexed queries plus one EdDSA signature, so throughput is bounded by your database, not by a lock. The architecture removes every per-tenant ceiling so you scale out, not up.

Stateless, horizontal

The engine holds no per-request state, every instance is identical and the verdict pipeline runs entirely within a tenant-scoped database transaction. To add capacity, add instances. The hot path is a handful of indexed queries plus one EdDSA signature; in steady state each stage runs in ~1-3 ms.

Heavy work runs off the hot path

  • ·Audit chaining, the request only appends to an outbox with an ordering sequence; a single-writer drain builds the hash chain and Merkle anchors afterwards. The verdict pays nothing for the audit guarantee.
  • ·Reasoning, the optional LLM pass is enqueued and applied after commit, so AI latency never touches the response or holds a connection.
  • ·Webhooks, delivery is decoupled; a slow endpoint can't slow a decision.

No per-tenant ceiling

The design deliberately avoids the locks that serialize tenants under load: ordering uses a global sequence rather than a per-org counter lock, and the trust read-modify-write uses a lock mode compatible with the inserts around it. Concurrent traffic for the same agent and the same tenant runs without deadlock or serialization.

These weren't assumed, they were found by load-testing the engine to failure and fixed. The result: many concurrent same-agent writes complete cleanly, and per-tenant throughput is bounded by the database, not by a lock.

Caching & pooling

  • ·The active policy is served from a per-instance cache (short TTL, single-flight, invalidated on activation), cutting a read per request.
  • ·Identity match is an O(1) thumbprint index, not a scan.
  • ·Connection pooling is sized for concurrent-per-instance compute; transactions are short, so a small pool serves high throughput.

What that looks like

StageTypical (warm)
kya~1 ms (indexed thumbprint)
policy~1-2 ms (cached active policy)
risk<1 ms (deterministic)
sign~1-2 ms (EdDSA)
persist~2-3 ms (single insert)
x-fidacy-server-timing: kya;dur=1, policy;dur=1, risk;dur=1, sign;dur=2, persist;dur=3, total;dur=9

Tail latency in production is dominated by network round-trips to the database region and cold starts, not the pipeline. Keep instances warm and co-locate compute with the database region for the tightest p99.

Durability & retention

  • ·Append-only audit tables are retained (detached, not dropped) to meet regulatory retention; high-churn tables (webhook deliveries) age out.
  • ·At very high sustained volume, the large append-only tables convert to declarative monthly partitions, an additive, online migration.