Developer guide

Reference deployment topology

3 min read

Where each component runs when a Partner operates the platform with real funds. The topology is deployed inside the Partner's own cloud project.

flowchart LR
    EXT[Partner app / backend and channels] -->|1| LB[Load Balancer / WAF]
    subgraph GCP[Partner's own cloud project]
        API[B2B API]
        CP[Control Plane]
        W[Workers]
        O[Observers]
        R[Reconciler]
        WH[Webhook Dispatcher]
        SG[Partner Signer Gateway]
        SQL[(Managed PostgreSQL, high availability)]
        PUB[Event bus]
        TASKS[Scheduled tasks]
        SM[Secret Manager / vault]
        AR[Artifact Registry]
        MON[Logging / Monitoring / Trace]
        LB -->|2| API
        API -->|3| SQL
        API -->|4| PUB
        PUB -->|5| W
        PUB -->|5| O
        PUB -->|5| R
        PUB -->|5| WH
        TASKS -->|6| W
        W -->|7| SG
        SG -->|8| SM
        API -->|9| MON
        W -->|9| MON
        O -->|9| MON
        R -->|9| MON
        WH -->|9| MON
    end
    W -->|10| RPC[RPC / blockchain providers]
    O -->|10| RPC
    WH -->|11| EXT

What each part does

  1. Partner app, backend and channels → Load Balancer. All external traffic enters through one controlled edge.
  2. Load Balancer → B2B API. The public contract, the only component external traffic reaches directly.
  3. API → PostgreSQL. The durable state: operations, ledger, identity, configuration.
  4. API → event bus. The Outbox is published here, and from here every consumer is fed.
  5. Bus → workers, observers, reconciler, webhook dispatcher. Delivery is at-least-once, so consumers deduplicate.
  6. Scheduled tasks → workers. Scheduled retries and sweeps: what has to happen later, not in response to a request.
  7. Workers → Partner Signer Gateway. The only path to a signature.
  8. Gateway → Secret Manager or vault. The gateway is the only component that can read the key material, under the Partner's own access control.
  9. Everything → Logging, Monitoring, Trace. Operational signals centralized.
  10. Workers and observers → RPC and blockchain providers. The only outbound path to the networks.
  11. Webhook dispatcher → Partner. Signed events back to the Partner's backend.

One deployment, one Partner

This topology serves exactly one Partner. The instance, the database, the secrets and the conversational instance are the Partner's own, and no part of them is shared with another Partner's deployment. It is the isolation model itself, not a starting configuration that later gets tightened.

Every record still carries the tenant it belongs to, so the data is portable to a shared deployment if one is ever offered, and so a report can be read per tenant. But a deployment refuses to start if its configured credentials name more than one tenant, and it refuses to register a client under a tenant that is not its own: what keeps one Partner's data away from another's here is that the other Partner is not in this instance.

Infrastructure responsibilities

  • The managed Kubernetes platform runs the API, workers, observers, reconciler, webhook dispatcher and signer as workloads with separate identities, so one compromised workload does not inherit the permissions of the others.
  • Managed PostgreSQL keeps the durable transactional state, with high availability.
  • The event bus distributes events at-least-once.
  • Scheduled tasks handle programmed retries and sweeps.
  • Secret Manager or a key vault stores the initial master secret and the other secrets, under the Partner's access control.
  • Artifact Registry keeps the images the Partner has imported and approved. They are private, and the cluster pulls from this registry and never from ChatterPay's: the image arrived here through an OCI copy that is a release step, so once the copy is done the deployment starts even if the origin registry is gone. ChatterPay can perform that copy -- and then the Partner needs no credential of ours -- or the Partner can, with read access, which is what lets it decide when to promote a version.
  • Logging, Monitoring and Trace centralize operational signals.

No central dependency

A real Partner's self-hosted deployment does not depend on a central ChatterPay service to sign or process operations.

ChatterPay publishes versioned artefacts; the Partner controls when they are promoted. That is what makes the Partner's operational continuity independent of ours.