Parix architecture

Parix is split into a Cloudflare-hosted control plane and a provider-hosted data plane.

Control plane

The control plane runs on Cloudflare and owns:

• the React Router web app
• Better Auth organization and membership flows
• D1 metadata for databases, profiles, backups, CDC, and billing
• KV and Durable Objects for low-latency state and read models
• R2 for snapshots and exported artifacts
• workflows for provisioning, upgrades, backups, and other long-running operations

Data plane

The data plane runs close to TigerBeetle and owns:

• TigerBeetle replicas
• tb-gateway for HTTP-to-TigerBeetle translation
• tb-tunnel for Cloudflare Tunnel connectivity into provider-local networking
• CDC transport components such as RabbitMQ and relay workers

Request flow

The current request path is:

1. Client sends a request to the Cloudflare entrypoint.
2. app-dispatcher authenticates the request and resolves the target provider route.
3. The request is forwarded through the provider-specific Workers VPC binding.
4. tb-tunnel carries the request privately into the provider network.
5. tb-gateway validates the request and performs the TigerBeetle operation.
6. The response travels back through the same private path.

CDC flow

CDC is a separate path from synchronous request handling:

1. TigerBeetle-adjacent services publish CDC messages.
2. RabbitMQ stores and fans out the messages.
3. tb-cdc-relay forwards batches to the Cloudflare-side ingest path.
4. Cloudflare queues and workflows handle downstream delivery and processing.

Operational consequences

This architecture means:

• TigerBeetle stays private to provider networking
• routing decisions remain provider-aware
• dashboard pages often read control-plane state rather than querying TigerBeetle directly
• some history views are eventually consistent by design

For the user-facing product surface, see Dashboard.