Hardware Spec: Component/Profile-Level Sizing (Single Site)

EFCX Hardware Sizing Within a Site

Overview

This gives the numeric CPU and RAM sizing for one production site of the platform: the vCPU/RAM footprint of each deployable workload profile, split between the Kubernetes-hosted profiles and the VM-based Voice subsystem. It is the numeric companion to efcx-kubernetes-workload-groups.md, which defines workload-group placement and node-pool grouping without numbers, and to efcx-kubernetes-deployment-architecture.drawio, which shows the node-pool topology those profiles land on.

Scope is a single site only. Duplicating this footprint for a second site, plus the cross-site clustering that goes with it, is a separate concern, see Out of scope.

Profile names below use the CX-<Name> Profile ID convention defined in efcx-kubernetes-workload-groups.md: the same ID identifies a given workload in both docs.

Kubernetes-hosted workload profiles

The companion efcx-kubernetes-workload-groups.md carries the full component-level detail, and further subdivides External by node pool (Edge, Stateful, Observability, Secrets) for high-availability and placement purposes: a placement view, distinct from the packaging-level bundling used here.

Voice subsystem profiles (VM-hosted)

These run on their own VM pool outside the Kubernetes cluster, per the placement rationale in the companion workload-groups doc: RTP media doesn’t fit ordinary ClusterIP/Ingress networking and needs direct external IPs.

Total compute footprint

This total excludes MongoDB, PostgreSQL, and any optional on-prem LLM/RAG GPU add-ons. Redis, MinIO, Keycloak, Grafana, ActiveMQ/Artemis, and APISIX are not broken out separately either: their footprint is carried within the CX-Core figures above, see Components without separate sizing and Out of scope.

Components without separate sizing

MongoDB and PostgreSQL run as platform-managed database services, sized by whatever platform-managed service hosts them rather than as fixed profile figures here. This matches their placement as platform-managed clustered data services in efcx-kubernetes-workload-groups.md.

Redis, MinIO, Keycloak, Grafana, ActiveMQ/Artemis, and APISIX carry the External CX-Profile tag in Expertflow’s component inventory, corresponding to the CX-Edge (Keycloak, APISIX) and CX-Stateful (Redis, ActiveMQ/Artemis) profiles in efcx-kubernetes-workload-groups.md, plus Grafana from that doc’s Observability pool. All six are co-located with the CX-Core profile (see the table above); that companion doc further splits them across its in-cluster Stateful, Edge & Identity, and Observability node pools for high-availability and placement purposes, a separate concern from this CX-Profile-level grouping. None of the six carry a vCPU/RAM figure of their own in the sizing data, so their footprint is carried within CX-Core’s 12 vCPU / 24 GB total rather than broken out separately.

Campaigns & Engagement, Surveys, and Quality Management (QM) are optional CX feature add-ons (profile IDs CX-Campaigns, CX-Surveys, CX-QM in efcx-kubernetes-workload-groups.md) that, when enabled, are co-located with the CX-Core profile rather than carrying their own dedicated-pool figure: their footprint is carried within CX-Core’s 12 vCPU / 24 GB total.

From workload totals to node-pool capacity

The figures above are workload requests, not raw node capacity to provision. Turning them into an actual worker node pool needs headroom for control-plane reservations and for Kubernetes’ node-loss relocation window, plus the per-component replica and quorum patterns (arbiter, Sentinel, anti-affinity) described in EFCX-High-Availability-Within-a-Site.md. That doc also covers why workload doesn’t automatically rebalance back once a recovered node rejoins, which affects how much slack a node pool needs to carry.

Rather than one uniform worker size, node counts and sizes below follow the five in-cluster node pools efcx-kubernetes-workload-groups.md already defines: Application (stateless, HPA-driven), Data-platform/batch, Stateful, Edge & Identity, and Secrets, plus Observability for Grafana. Each pool’s node count follows that pool’s own replica/anti-affinity pattern rather than a single N-1 rule applied uniformly, and its size follows what that pool’s components actually need rather than a copied per-node figure.

CX-Core’s 12 vCPU/24 GB bundle carries several of these destinations at once: its own first-party services (Application), plus the co-located External-tagged infra with no component-level split published yet (Redis and ActiveMQ/Artemis into Stateful, Keycloak and APISIX into Edge & Identity, Grafana into Observability). The per-pool split below is therefore a rough estimate, not a measured figure, roughly 60/20/15/5 percent of that bundle across Application/Stateful/Edge/Observability respectively. It should be replaced once real per-component numbers exist, per the “Numeric sizing” open item in the workload-groups doc.

This spreads the same rough total across more, smaller instances instead of three large uniform workers. Whether the four lighter in-cluster pools (Stateful, Edge & Identity, Secrets, Observability) stay fully separate or get consolidated onto fewer shared nodes with logical isolation (namespaces plus anti-affinity within one pool) is an open call for whoever finalizes the deployment, not settled here: it trades node count against operational isolation, and the right answer depends on what the hosting platform makes cheap to operate.

A coarser alternative, two uniform worker nodes instead of six dedicated pools, is laid out and compared against this option in EFCX-Hardware-Sizing-Node-Pool-Options.md.

The Kubernetes worker and control-plane sizing here is a generic reference baseline, not a fixed requirement: exact instance sizes should be matched to whatever generic instance sizes the hosting platform offers. The 39 vCPU/78 GB worker pool figure (1.5x the raw 26 vCPU/52 GB workload total) is what the N-1 rule drives; it doesn’t yet add per-node OS/kubelet reservations, which further reduce allocatable capacity below each instance’s raw size and should be applied using the hosting platform’s own overhead figures at implementation time. The Voice VM tier isn’t given the same N-1 treatment: CX-Media already runs 2 instances per the table above, and this note maps hosts 1:1 to those instances rather than layering on further host-loss headroom.

Out of scope

• Second-site duplication. This note is single-site. Mirroring it for a second site, and the cross-site clustering/DR mechanics on top, is covered separately in EFCX-High-Availability-Across-Two-Sites.md.

• On-prem LLM/RAG GPU sizing. GPU figures exist for on-prem LLM inference and embedding generation, but they belong to a different, VM-oriented sizing model and aren’t reused here.

• Conversation-volume-to-profile mapping. This note doesn’t state which conversation-volume tier its totals correspond to. A separate, older VM-based sizing model sizes by conversation volume (50/100/300/500/1000); the two models aren’t reconciled, so no supported-conversations figure is quoted alongside the numbers above.

• Optional add-on profiles outside standard deployment. CX-Rasa-X-Connector, the fifteen CX-Channel-* digital-channel connectors, and CX-CRM connectors aren’t part of this baseline: each is enabled per customer/tenant and carries its own separate profile and sizing requirements when turned on, not a fixed figure this single-site footprint can carry. CX-Observability’s non-Grafana components (Prometheus, node-exporter, Alertmanager, ElasticSearch, Kibana) are managed and owned by the underlying platform and customer/partner, not by EFCX, so no EFCX sizing figure applies to them either.