Data flows
Service-to-service traffic patterns in a production OpenBox deployment. See Component diagram for the visual companion.
Traffic table
| Traffic | Path | Protocol | Purpose |
|---|---|---|---|
| User HTTPS | ALB → Istio Gateway → openbox-core-server / openbox-backend / openbox-fe / temporal-web / openbox-core-codec | HTTPS 443 | UI + API entry point |
| Workflow start | openbox-core-{governance,attestation,observability}-worker + scheduler → temporal-frontend :7233 → temporal-history / temporal-matching → PostgreSQL + Elasticsearch | gRPC 7233 | Async orchestration |
| Auth (OIDC) | openbox-backend + openbox-core → identity-service (Keycloak) | HTTPS OIDC | User identity, JWT tokens |
| Policy decision | openbox-backend + openbox-core → opa-app :8181 | HTTP/JSON | Authorization rules |
| Guardrails inference | openbox-core → guardrails-api :8000 → model-host-detect-pii / model-host-nsfw / model-host-toxicity | HTTP/REST | CPU ML content filter |
| Prompt injection detection | openbox-core → llamafirewall-server → vllm (Qwen3-8B) | HTTP/REST | Deep LLM analysis (GPU) |
| Envelope encryption | openbox-backend + openbox-core → AWS KMS | HTTPS AWS API | Encrypt/decrypt data at rest |
| Policy bundle pull | opa-app ← S3 GET | HTTPS S3 API | Periodic policy CDN refresh |
| Session cache | openbox-core-server ↔ openbox-core-redis :6379 | Redis TCP | Session state |
| App DB | openbox-backend ↔ openbox-postgresql :5432 | JDBC | Transactional storage |
| Identity DB | identity-service ↔ openbox-identity-postgresql :5432 | JDBC | Keycloak realms/users/tokens |
| Temporal store (self-hosted only) | temporal-frontend/history/matching ↔ openbox-postgres-temporal :5432 | JDBC | Workflow history |
Latency targets (internal SLO)
| Path | p50 | p99 |
|---|---|---|
| Internal REST call | < 5 ms | < 20 ms |
gRPC to temporal-frontend | < 3 ms | < 15 ms |
| KMS Encrypt / Decrypt | < 50 ms | < 200 ms |
| S3 GET (OPA bundle refresh) | < 100 ms | < 500 ms |
| Guardrails CPU inference | < 200 ms | < 800 ms |
| LlamaFirewall + vllm inference | < 500 ms | ~2000 ms |
Targets are per-service — not cross-service transaction time. E2E user-facing latency depends on how many services a request touches.
East-west vs north-south
- North-south (user → cluster): only the Istio Gateway is exposed externally. All other services are cluster-internal.
- East-west (service → service): Istio sidecar auto-injects mTLS between pods (chart default). Turning Istio off = plaintext east-west; combine with NetworkPolicy for defense-in-depth.
Failure modes to know about
openbox-coreworkers cannot start workflows iftemporal-frontendis unreachable — pods stay Running but log connection errorsguardrails-apiHPA panics under sudden traffic spikes (fixed 2-min metrics window); pre-warm before load testsopa-apppulls bundle at startup — if S3 is unreachable, pod is Ready but has empty policy = default-deny for all requests- KMS API throttling at extreme scale (~500 rps per key) — envelope encryption's DEK caching absorbs most of this