One design, used for every customer. Cloud-specific differences — the connectivity product, the key service, the database engine — are configuration choices, not redesigns. That is what makes an environment buildable from code in five working days.
Reading the picture from the top
- Users and integrations arrive at one name, erp.<customer domain>, and reach a load balancer with a WAF over HTTPS, TLS 1.2 or higher. It is the only public way in.
- At least three worker nodes, one per availability zone, run web and API, the posting engine, the ASK operator, and workers and jobs. Losing a node or a whole zone leaves capacity serving users.
- The managed database — engine and size of the customer’s choice — has a synchronous standby in another zone. A zone failure loses nothing: RPO ≈ 0.
- Documents and attachments live in versioned object storage, not in the database.
- Outbound traffic leaves through NAT to an allow-list: banks, tax and e-invoicing, payroll, email, the AI engine. Nothing else.
- Backups are pushed one way to an air-gapped vault in a separate account.
The private endpoint and internal load balancer are drawn dashed because they exist only when private access is used. With HTTPS-only access they are not built.
Five knobs, and nothing else
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.
Configure, integrate, and only then code
A requirement beyond standard is met by configuration if it can be — upgraded with the platform. If not, by an integration through TRANXACT APIs running outside the cluster. Only then is code or an agent inside the cluster considered, after a security and engineering review; if approved it is tolerated and customer-supported, and if rejected it runs outside.
There is no direct database access for the customer — it is marked not offered (DB_3.1.09). Reporting and integration go through TRANXACT APIs and extracts, which is also why a BI tool is connected by API or scheduled extract, never by a database login.
Calderwood’s BI team asks for a read-only database user for their warehouse. The answer is a scheduled extract over private link — the BI row on their interface list is "keep, scheduled extract, private link".
Try it A worker node in zone 2 fails during Calderwood’s month-end. What happens to users, and does it count against the SLA?
Its pods are rescheduled onto the nodes in zones 1 and 3, which were sized to carry the load; the database is unaffected unless zone 2 held the primary, in which case it fails over to the synchronous standby with RPO ≈ 0. It counts against the SLA only if the month’s availability misses the tier target.