Known Limitations · STANDALONE Mode Performance

[contexa73]

Known Limitations · STANDALONE Mode Performance

Labels: known-issue, documentation
Assignee: @contexa73
Type: Transparency note

Why this issue exists

We want our limitations to be public. Operators choosing between STANDALONE and DISTRIBUTED infrastructure modes should know exactly what STANDALONE can and cannot do, before they hit production constraints.

This issue documents known constraints — not bugs.

STANDALONE mode summary

• Storage: in-memory (no Redis · no Kafka)
• Target use case: development environments, small single-instance deployments, evaluation
• Configuration: contexa.infrastructure.mode: standalone

Known limitations

1. No horizontal scaling

The decision authority cache and ZeroTrust action repository are held in ConcurrentHashMap. Multiple instances of the application cannot share decision state. If you scale horizontally, each instance will compute decisions independently — producing inconsistent runtime behavior.

Mitigation: switch to DISTRIBUTED mode (Redis + Kafka).

2. Decision state lost on restart

In-memory storage means a JVM restart loses every active decision (CHALLENGE awaiting MFA, ESCALATE awaiting human review, etc.). Users mid-flow will be re-evaluated from a clean slate.

Mitigation: rolling restarts only after notifying users; or DISTRIBUTED mode.

3. Cross-instance event broadcast unavailable

SecurityPlaneAgent stripe distribution requires Kafka in DISTRIBUTED mode. STANDALONE serializes all events through a single in-process executor — throughput is bounded by one JVM's CPU.

Practical ceiling: ~200–400 protected requests / second on a 4-core machine (varies with prompt complexity and LLM latency).

4. No verification ledger persistence

The Official Verification ledger (sealed evidence + 15-metric runs) writes to the database in DISTRIBUTED mode but uses an in-memory ConcurrentHashMap in STANDALONE. After restart, run history is lost.

Mitigation: DISTRIBUTED mode for any verification campaign that needs to survive restarts.

5. HCAD baseline reset on restart

The 9-dimension behavioral baseline (EMA α=0.1 + LFU per-dimension) is in-memory in STANDALONE. After restart the baseline restarts from organization seed. Personal baselines re-learn over the first ~50 requests per user.

Mitigation: DISTRIBUTED mode persists baselines to Redis with 30-day TTL.

When STANDALONE is the right choice

• Local development and integration testing
• Small internal tools with one instance
• Initial proof-of-concept evaluations
• CI / CD verification harnesses

When you must use DISTRIBUTED

• Any production deployment with horizontal scaling
• Any deployment where decision continuity across restarts matters
• Any deployment running the Open Trust Benchmark verification campaigns
• Anywhere request volume exceeds ~200 / second sustained

How to flag improvements

If you hit a STANDALONE limitation that is not listed here, comment below with:

• Your traffic profile (req/s, instance count)
• The exact symptom you observed
• The fallback you used

We will fold real-world reports into this list and into the official infrastructure decision guide.