Skip to main content

FoundationDB Cluster Information

Cluster Details​

Cluster Name: coditect:production

Endpoints:

  • 10.0.1.3:4500
  • 10.0.1.4:4500
  • 10.0.1.5:4500

Cluster File (fdb.cluster):

coditect:production@10.0.1.3:4500,10.0.1.5:4500,10.0.1.4:4500

Deployment​

  • Platform: Google Kubernetes Engine (GKE)
  • Cluster: codi-poc-e2-cluster (us-central1-a)
  • Nodes: 3-node StatefulSet
  • Version: FoundationDB 7.1.x
  • Storage: Persistent volumes in GKE

Network Access​

From Cloud Run (V5 Backend):

  • Access via VPC Connector: fdb-connector
  • VPC Network: fdb-network
  • IP Range: 10.8.0.0/28
  • Connector Status: READY

Internal IPs:

  • 10.0.1.3:4500
  • 10.0.1.4:4500
  • 10.0.1.5:4500

Secret Storage​

The cluster file is stored in Google Secret Manager:

  • Secret Name: fdb-cluster-file
  • Project: serene-voltage-464305-n2
  • Access: Via Cloud Build and Cloud Run service accounts

Database Schema (V5)​

Key Patterns​

users/{user_id}                          → User record (JSON)
users/by_email/{email}                   → user_id (UUID bytes)
users/{user_id}/tenants/{tenant_id}      → UserTenant association (JSON)

tenants/{tenant_id}                      → Tenant record (JSON)
tenants/{tenant_id}/sessions/{session_id}→ session_id (UUID bytes)

sessions/{session_id}                    → Session record (JSON)

Example Operations​

Create User:

SET users/{uuid} = {"user_id": "...", "email": "...", ...}
SET users/by_email/user@example.com = {uuid_bytes}

Create Session:

SET sessions/{session_uuid} = {"session_id": "...", "tenant_id": "...", ...}
SET tenants/{tenant_uuid}/sessions/{session_uuid} = {session_uuid_bytes}

Lookup User by Email:

GET users/by_email/user@example.com  → user_id
GET users/{user_id}  → User record

Connection from Backend​

The Rust backend connects to FDB using:

// From backend/src/db/mod.rs
let cluster_file = std::env::var("FDB_CLUSTER_FILE")
    .unwrap_or_else(|_| "/app/fdb.cluster".to_string());

let database = Database::new(Some(&cluster_file))?;

Environment Variables:

  • FDB_CLUSTER_FILE=/app/fdb.cluster (mounted from secret)

Monitoring​

Check FDB cluster status:

# From GKE cluster (requires kubectl access)
kubectl get pods -l app=foundationdb
kubectl exec -it foundationdb-0 -- fdbcli --exec status

ACID Guarantees​

FoundationDB provides:

  • ✅ Atomicity: All operations in a transaction succeed or fail together
  • ✅ Consistency: Database always in valid state
  • ✅ Isolation: Snapshot isolation (serializable)
  • ✅ Durability: Committed data survives failures

Transaction Limits:

  • Max transaction size: 10 MB
  • Max keys per transaction: ~100,000
  • Transaction timeout: 5 seconds (default)

Multi-Tenancy​

V5 uses key prefixing for tenant isolation:

users/{user_id}/tenants/{tenant_id}/...
tenants/{tenant_id}/sessions/{session_id}/...

All queries filter by tenant_id from JWT claims to ensure data isolation.

Backup & Recovery​

Backup Strategy (V4 reference):

  • Continuous backup to Google Cloud Storage
  • Point-in-time recovery (PITR)
  • Automated backup snapshots

Recovery:

# Restore from backup (requires fdbbackup tool)
fdbbackup restore --dest-cluster-file /etc/foundationdb/fdb.cluster \
  --restore-from gs://bucket/backup/

Performance​

Expected Performance (from V4 benchmarks):

  • Read latency: 1-5ms (p50)
  • Write latency: 5-10ms (p50)
  • Throughput: 10k+ ops/sec per node
  • Scalability: Horizontal (add more nodes)

Security​

  • Encryption: TLS in transit (if configured)
  • Access Control: Network-level (VPC, firewall rules)
  • Authentication: Cluster file acts as shared secret
  • Audit: All operations logged to backend logs

References​