Skip to content
SiteSwarm Platform Documentation

Multi Worker Platform Services

Multi-Worker Platform Services & Service Binding Topology

1. Executive Summary & Design Rationale

In SiteSwarm, the parts of a client web application that serve public visitors (apps/<client>) must remain fast, lean, and free of bundle bloat. Heavy dependencies, administrative interfaces, database drivers, and privileged platform coordination are offloaded into separate Cloudflare Workers connected via internal Cloudflare Service Bindings.

Whether a capability is app-hosted (deployed as a dedicated service worker alongside a specific client app, such as its CMS) or platform-hosted (deployed as a shared central service worker, such as Critiques or Cache Purge; see CAPABILITY_MANAGEMENT.md), running it in a separate worker isolate ensures the public-facing application worker stays fast and unbloated.

flowchart TD
    Visitor["Public Visitor"] --> PublicApp["Client Public Worker (apps/<client>)\nFast, Lean Visitor Path"]
    PublicApp <-->|"Service Binding"| AppHostedWorker["App-Hosted Service Worker\n(e.g. Dedicated Client CMS)"]
    PublicApp <-->|"Service Binding"| SharedService["Platform-Hosted Service Worker\n(e.g. Critiques / Cache Purge)"]

2. Public Frontend Worker vs. Backing Service Workers

Splitting heavy or privileged workloads into separate workers protects the performance and security profile of the visitor-facing application:

Dimension Public Client Worker (Fast Visitor Path) Backing Service Worker (app-hosted or platform-hosted)
Primary Workload Visitor page rendering, static asset delivery, and lightweight route forwarding. Heavy administrative studios (e.g., CMS), database mutations, media processing, and cross-tenant services.
Bundle & Cold-Start Profile Kept strictly minimal so visitor requests never pay the cold-start or memory cost of admin frameworks or heavy SDKs. Isolates large dependencies and administrative logic into a separate worker runtime that only runs when invoked.
Storage & Secret Bindings Holds no privileged cross-tenant platform credentials; may attach lightweight dedicated app-hosted bindings only when they do not impact caching or bundle speed (DATA_STORAGE_PATTERN.md). Isolates heavy app-hosted or platform-hosted database/storage bindings and sensitive API credentials.
Failure Blast Radius Remains fast and available (backed by edge cache) even if an administrative or background service worker experiences load. Faults or heavy operations are contained within the backing worker isolate.

3. Inter-Worker Communication & Security Invariants

  1. Internal Service Bindings: Worker-to-worker communication between a client frontend worker and its backing services uses native Cloudflare Service Bindings, avoiding public network latency and external credential exposure.
  2. Explicit Tenant Context: Requests routed to shared platform-hosted services carry explicit tenant identification so multi-tenant services enforce strict per-client partitioning.
  3. Credential Isolation: Privileged platform tokens (such as Cloudflare zone purge tokens or external notification secrets) reside exclusively inside the backing service worker environment, never in public client frontend workers.