ToFF Form: System Architecture

Powered by Formbricks v6

Managed by CultureOS

This technical specification details the microservice architecture, container topology, host resource sizing, and disaster recovery mechanics powering ToFF Form (https://form.tomoffinland.org).

System Operations & Engineering

This operational system is configured, deployed, and managed by CultureOS. CultureOS is an AI-native practice helping cultural institutions modernize digital infrastructure, archives, and research workflows responsibly.

Architectural Overview

Formbricks v6 is engineered as a distributed microservice stack rather than a single monolithic container. ToFF Form orchestrates six synchronized container services on host personal-assistant (40.160.54.226), reverse-proxied by Caddy v2 with automated Let's Encrypt TLS:

                            [ Public Ingress / HTTPS (443) ]
                                           │
                                           ▼
                            [ Caddy v2 Automated Reverse Proxy ]
                            (Port 80/443, TLS 1.3, Static Routing)
                                           │
                                           ▼
                                 [ 127.0.0.1:3005 ]
                                           │
    ┌──────────────────────────────────────┴──────────────────────────────────────┐
    │                       Docker Bridge Network (Internal)                      │
    │                                                                             │
    │  ┌───────────────────────┐                        ┌──────────────────────┐  │
    │  │ formbricks-formbricks │ ── gRPC:50051 (ReBAC) ─>│  formbricks-spicedb │  │
    │  │ (Next.js 14 Web App)  │                        │  (Authzed v1.52.0)   │  │
    │  └───────────┬───────────┘                        └──────────┬───────────┘  │
    │              │                                               │              │
    │              │ ── SQL:5432 ───────────────┐                  │              │
    │              │                            │                  │              │
    │              │ ── Redis:6379 ─────────┐   │                  │              │
    │              ▼                        ▼   ▼                  ▼              │
    │  ┌───────────────────────┐         ┌───────────────┐  ┌──────────────────┐  │
    │  │   formbricks-hub      │         │  PostgreSQL   │  │    PostgreSQL    │  │
    │  │ (Async Event Worker)  │         │   (pgvector)  │  │ (spicedb schema) │  │
    │  └───────────┬───────────┘         └───────────────┘  └──────────────────┘  │
    │              │                            ▲                                 │
    │              ▼                            │                                 │
    │  ┌───────────────────────┐                │                                 │
    │  │    formbricks-cube    │ ── SQL:5432 ───┘                                 │
    │  │ (Analytics Aggregator)│                                                  │
    │  └───────────────────────┘                                                  │
    └─────────────────────────────────────────────────────────────────────────────┘

Hardware & Resource Sizing Matrix

Based on official Formbricks v6 benchmarks and Foundation operational requirements:

Deployment Tier	Minimum vCPU	Minimum RAM	SSD Storage	Operational Scope & Target Use Case
Evaluation / Staging	2 vCPU	4 GB	20 GB SSD	Basic testing, local development, template authoring
Foundation Production (Current)	4 vCPU	8 GB	50 GB SSD	Production intakes, multi-jury scholarship cycles, media uploads
High-Concurrency Cluster	3x Nodes (4 vCPU / 8 GB)	24 GB+	Managed S3 / RDS	Global multi-million respondent campaigns with autoscaling

Headroom & Buffer Guidelines

A 4 GB memory allocation represents the absolute baseline floor. Running with 8 GB ensures ample headroom for high-resolution artist portfolio PDF uploads, concurrent survey bundle rebuilds, and asynchronous email queue processing.

Performance Dynamics & Load Behavior

Sizing for Response Bursts (Queue Dynamics)

Handling burst traffic (such as an exhibition opening or grant deadline announcement) is primarily a queue sizing challenge rather than a raw request-rate challenge:

• Each submission enqueues multiple asynchronous pipeline tasks:
  1. responseCreated: Registers submission intent;
  2. responseUpdated: Dispatched for each individual progress step saved;
  3. responseFinished: Finalizes evaluation, triggers email confirmations, and fires external webhooks.
• Redis Protection: Redis is pinned with maxmemory-policy noeviction. If queue volume exceeds limits, Redis temporarily refuses writes rather than dropping in-flight submissions, ensuring zero data loss.

Sizing for Large Contact Lists

Contact attributes scale storage linearly rather than throughput. Each contact attribute consumes one dedicated relational row. Therefore, managing 50,000 artist contacts with 10 demographic attributes requires 500,000 database rows prior to recording individual survey responses.

Caddy Edge Reverse Proxy Configuration

Caddy terminates external TLS and implements surgical routing overrides:

form.tomoffinland.org {
    # 1. Direct Static Font Ingress
    handle /fonts/* {
        uri strip_prefix /fonts
        root * /opt/formbricks/branding/fonts
        file_server
    }

    # 2. OpenGraph & Social Sharing Cards
    handle /og-preview.png {
        root * /opt/formbricks/branding
        file_server
    }

    # 3. Next.js Static Cache Lock Bypass
    handle /_next/static/media/formbricks-wordmark* {
        rewrite * /branding/toff-wordmark.svg
        root * /opt/formbricks
        header Cache-Control "no-cache, no-store, must-revalidate"
        header Content-Type "image/svg+xml"
        file_server
    }

    # 4. Proxy to Local Web App Container
    handle {
        reverse_proxy 127.0.0.1:3005 {
            header_up Host {upstream_hostport}
            header_up X-Real-IP {remote_host}
            header_up X-Forwarded-For {remote_host}
            header_up X-Forwarded-Proto {scheme}
        }
    }
}

120-Second Instant Cloud Disaster Recovery

In the event of physical host catastrophe:

1. Cold Recovery Execution: Execute scripts/dr-restore-cloud.sh on any fresh Ubuntu 22.04 LTS host.
2. Autonomous Restoration: Docker, Restic, and PostgreSQL 18 snapshots are reconstituted automatically.
3. Ingress Activation: Caddy pulls Let's Encrypt certificates within 10 seconds of DNS propagation.
4. Target Metrics: RTO < 120 seconds, RPO < 6 hours.