Spicedb High‑Throughput Deployment with a Single‑Redis Backend

Key Requirements for a Read‑Heavy Authorization Service

When the workload is dominated by authorization checks, Spicedb must deliver sub‑millisecond latency while keeping relation tuples strongly consistent. The design below satisfies four core constraints:

• High read throughput (10k+ queries/s) with <5 ms average latency.
• Zero‑downtime policy updates and audit‑ready decision logs.
• Per‑tenant isolation via namespace scoping.
• Strong consistency for tuple writes using Redis cluster replication.

Smallest Viable Architecture

The minimal stack consists of a single Spicedb container per tenant namespace, a dedicated Redis cluster in cluster mode, and a TLS‑enabled load balancer that terminates traffic before forwarding to Spicedb. The containers are stateless; all persistence and cache resides in Redis. Secrets (Redis password, TLS certs) live in a secrets manager and are injected at runtime.

docker run \
  --name spicedb-tenant1 \
  -e SPICE_DB_REDIS_URL=redis://:${REDIS_PASSWORD}@REDIS_HOST:6379 \
  -e SPICE_DB_NAMESPACE=tenant1 \
  -e SPICE_DB_TLS_CERT=/certs/server.crt \
  -e SPICE_DB_TLS_KEY=/certs/server.key \
  -v /secrets:/secrets \
  ghcr.io/authzed/spicedb:latest

Redis is configured with cluster-enabled yes, cluster-require-full-coverage no, and AOF persistence (fsync=everysec) to balance durability and speed. Keyspace notifications are turned on with notify-keyspace-events Ex so Spicedb can invalidate its local cache on tuple changes.

Trust and Data Boundaries

Spicedb trusts the Redis cluster for durable storage but must enforce tenant scoping at the application layer. Requests are authenticated via OAuth2 or JWT; the token must contain a tenant claim that matches the Spicedb namespace. The API rejects any tuple write or read that references a namespace different from the authenticated tenant.

Example policy: allow read on resource if subject is in group "admins". The tuple user:alice -> member_of -> group:admins is stored under the tenant1 namespace. A request from tenant2 will never be able to read that tuple because Spicedb filters by namespace before querying Redis.

Operational Checks & Monitoring

1. Health Endpoint – /healthz returns ok only if Redis connectivity and quorum are verified. Exposed at https://lb.example.com/spicedb/healthz.

   curl -k https://lb.example.com/spicedb/healthz
   

2. Cache Invalidations – Redis keyspace notifications trigger a Redis Pub/Sub channel that Spicedb listens to. Verify by inspecting the spicedb-cache-misses metric after a bulk import.

   redis-cli --cluster call REDIS_HOSTS 6379 cluster nodes
   

3. Correlation IDs – Each request must carry a X-Request-ID header. Spicedb logs include this ID, enabling end‑to‑end tracing with OpenTelemetry.
4. Metrics – Prometheus scrapes spicedb_query_latency_seconds, spicedb_cache_hit_ratio, and spicedb_tuple_write_rate. Alert on latency > 10 ms or cache hit ratio < 90%.

Failure Modes and Mitigations

Failure Mode	Impact	Mitigation
Redis node failure	Degraded performance; possible quorum loss.	Redis cluster replication keeps data available; Spicedb continues to serve requests with minor latency increase.
Bulk tuple import	Latency spikes during write bursts.	Throttle imports; use redis-cli BGSAVE to offload persistence.
Misconfigured namespace	Cross‑tenant data leakage.	Enforce strict namespace checks; audit logs record namespace per tuple.
Stale cache entries	Incorrect decisions until eviction.	Configure Redis maxmemory-policy allkeys-lru and set TTL on tuples.

When the Design Needs to Evolve

• Write‑Heavy Workloads – If the ratio of tuple writes to reads rises above 30%, consider deploying multiple Spicedb nodes per namespace with a shared Redis cluster, or switch to a multi‑region Redis setup.
• Cross‑Tenant Policy Evaluation – When policies must reference tuples from other tenants, a global namespace layer or a policy‑evaluation service that aggregates namespaces is required.
• Regulatory Persistence Requirements – On‑prem or immutable storage mandates moving from Redis to Cassandra or Postgres; Spicedb now supports these backends but may need additional tuning.
• Scaling Beyond Millions of Tuples – Sharding Spicedb instances by tenant or logical partition and routing queries to the correct shard becomes necessary.

Practical Verification Checklist

1. Run wrk -t4 -c100 -d30s -R10000 https://lb.example.com/spicedb/v1/lookup and confirm Latency < 5 ms.
2. Import 1 M tuples via spicedb tuple import --namespace tenant1 --file tuples.json and watch redis-cli cluster info for cluster_state:ok.
3. Update a tuple, then immediately query the same resource; check the audit log timestamp to ensure a decision update within 1 s.
4. Simulate a Redis shard failure by stopping one node; verify Spicedb health still reports ok and latency increases by +10%.

These steps provide a conservative, repeatable test of the design’s resilience and performance before moving to production.