Reference architecture and runtime
What is built in the customer’s cloud: the ingress, the three-node Kubernetes cluster across zones, the managed database with its standby, object storage, egress, the air-gapped vault, and the sizing knobs.
Every deployment is designed once against the same reference architecture. Differences between clouds — connectivity products, key management, database engines — then become configuration choices rather than redesigns.
| Design | Build | Operate | Innovate |
|---|---|---|---|
| One data model and one posting engine for every financial event. | Containerised services on a three-node, load-balanced Kubernetes cluster. | Immutable postings and a full audit trail by design. | ASK acting through TRANXACT’s own APIs. |
| Multi-entity, multi-currency, multi-region by design. | A managed database of the customer’s choice, sized for high availability. | Live DR in a second running region, and air-gapped backups as standard. | A role-aware action queue that learns what matters. |
What is inside one region
| Component | What it is | Notes |
|---|---|---|
| Load balancer and WAF | HTTPS ingress at erp.<customer domain>; TLS 1.2 or higher; DDoS protection. | The only public entry point. |
| Private endpoint / internal load balancer | Ingress for private traffic over VPN, private connection or peering. | Present when private access is used. |
| Kubernetes cluster | At least three worker nodes spread across availability zones, TLS end to end. | Runs web and API, the posting engine, the ASK operator, and workers and jobs. |
| Managed database | A primary with a synchronous HA standby in another zone. | Engine and size are the customer’s choice. |
| Object storage | Documents and attachments, versioned, replicated across regions. | Documents do not live in the database. |
| NAT egress | Outbound traffic only to an allow-list of destinations. | Banks, tax and e-invoicing, payroll, email, the AI engine. |
| Air-gapped vault | A separate account holding immutable, write-once backups. | Production can push to it and nothing else. |
The worker nodes are spread across zones so that losing one node or one zone still leaves capacity serving users. Where each service runs on which node is illustrative in the guide — the scheduler places them.
Outside the cluster
- The AI engine for ASK — premium, balanced or economy tier, or the customer’s own key (BYOK).
- External services — banks, tax and e-invoicing, payroll, BI and data platforms, email.
- Remote and mobile users, signing in through the customer’s identity provider.
- The customer’s corporate network: office users, the identity provider, legacy and shop-floor systems — reached over VPN or private link when private connectivity is used.
Private connectivity is optional. When all access is over HTTPS, the VPN / private link and the internal load balancer are simply not built.
The sizing knobs
- Node size.
- Node count — three at minimum.
- Database engine and size.
- The Live DR region.
- The number of environments.
Everything else is the reference architecture and is the same for every customer. See Before the contract for the usage tiers that set the starting values.
Configure, don’t customise
The same principle governs what runs in the cluster. A requirement beyond standard is met, in this order: by configuration (low-code / no-code, upgraded with the platform); by an integration through TRANXACT APIs that runs outside the cluster; and only then, after a security and engineering review, by code or an agent inside the cluster — which, if approved, is tolerated and customer-supported. Rejected code runs outside the cluster. The X chapter of the workbook lists the tasks for each outcome.
Anything achievable by configuration must not become custom code. Configuration moves with every platform release; custom code does not.