ExamFinch.com My Study

Study guide

12.1 CloudHub 1.0 & 2.0 Architecture: Workers, vCores & Clustering

Practice this exam

Salesforce Certified MuleSoft Developer I Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Creating Application Networks & API-Led Connectivity

1.1 The IT Delivery Gap & API-Led Connectivity Architecture 1.2 Application Network Foundations & Center for Enablement (C4E) 1.3 Anypoint Platform Architecture & Core Components

2 Chapter 2: Designing APIs with RAML & API Designer

2.1 RAML 1.0 Fundamentals, Data Types & Resource Hierarchy 2.2 Reusable API Fragments, ResourceTypes & Traits 2.3 API Mocking Service, Documentation & Anypoint Exchange Publishing

3 Chapter 3: Accessing and Modifying Mule Events

3.1 Mule 4 Event Architecture: Message, Payload, Attributes & Variables 3.2 Flow Variable Management & Target Variables Pattern 3.3 Accessing Event Metadata, Inbound Attributes & Context Properties

4 Chapter 4: Structuring Mule Applications

4.1 Modular Flow Composition: Flows, Subflows & Private Flows 4.2 Configuration Property Files & Environment Management 4.3 Secure Properties Tool, Encryption & Maven Project Packaging

5 Chapter 5: Building API Implementation Interfaces

5.1 APIkit Scaffolding, Router Configuration & Interface Generation 5.2 HTTP Listener Configuration, Path Matching & Query/URI Parameters 5.3 Interface vs. Implementation Separation & Backend Flow Wiring

6 Chapter 6: Using Connectors & External Systems

6.1 Database Connector: Select, Insert, Update, Stored Procedures & Watermarking 6.2 HTTP Request Connector: Headers, Query Params, Response Timeouts & Target Variables 6.3 Salesforce Connector, JMS Messaging & File/FTP Connectors

7 Chapter 7: Processing Records & Batch Integration

7.1 For Each Scope: Payload Iteration, Batch Size & Streaming Data 7.2 Batch Job Architecture: Input, Process, and Complete Phases 7.3 Batch Step Accept Expression, Failure Handling & Batch Aggregator 7.4 Object Store: Persisting Data Between Flow Executions

8 Chapter 8: Transforming Data with DataWeave 2.0

8.1 DataWeave 2.0 Syntax, Type System & Selectors 8.2 Core Functions: map, filter, pluck, reduce, groupBy & orderBy 8.3 Custom Functions, Format Transformations & Type Coercion 8.4 Calling Mule Flows from DataWeave & Reusing DataWeave Modules

9 Chapter 9: Routing Events & Flow Control

9.1 Choice Router: Conditional Expressions & Default Routing 9.2 Scatter-Gather Router: Parallel Execution, Aggregation & Error Traps 9.3 Async Scope, Round Robin & First Successful Routing 9.4 Validating Mule Events with the Validation Module

10 Chapter 10: Handling Errors & Exception Management

10.1 Mule 4 Error Object Hierarchy & Custom Error Types 10.2 On-Error Continue vs. On-Error Propagate Mechanisms 10.3 Try Scope Exception Isolation & Global Error Handling Strategies

11 Chapter 11: Debugging and Troubleshooting Mule Applications

11.1 Logger Configuration, Categories & Thread/Context Diagnostics 11.2 Anypoint Studio Debugger: Breakpoints, Expression Watches & Step-Through 11.3 MUnit 2.x Testing: Unit Tests, Mocking Connectors & Assertions

12 Chapter 12: Deploying and Managing APIs and Integrations

12.1 CloudHub 1.0 & 2.0 Architecture: Workers, vCores & Clustering 12.2 Runtime Manager: Application Management, Alerts, Insights & Logs 12.3 API Manager: Auto-Discovery, API Gateway, SLA Tiers & Standard Policies

12.1 CloudHub 1.0 & 2.0 Architecture: Workers, vCores & Clustering

Key Takeaways Explain This Topic AI

CloudHub workers are dedicated virtual machine instances running isolated Mule runtime JVMs; worker sizing ranges from fractional vCores (0.1 vCore = 500 MB heap / 1.5 GB memory) to multi-vCore instances (up to 16 vCores = 32 GB heap / 64 GB memory).

Horizontal scaling (deploying 2+ workers) delivers high availability across AWS Availability Zones and automatic load balancing, whereas vertical scaling (increasing vCore size) provides larger JVM heap memory for compute-intensive batch processing.

The CloudHub Shared Load Balancer (SLB) routes public traffic (app-name.region.cloudhub.io on ports 8081/8082) in round-robin fashion, while a Dedicated Load Balancer (DLB) enables custom domains, custom SSL/TLS termination, and internal VPC routing.

CloudHub 1.0 deploys applications on AWS EC2 virtual machines inside Anypoint VPCs, whereas CloudHub 2.0 provides containerized Kubernetes deployments on Salesforce Hyperforce substrate using Shared Spaces and Private Spaces.

Static IP addresses can be explicitly allocated to workers in CloudHub 1.0 to satisfy external firewall whitelisting requirements, and persist across application restarts and redeployments.

Last updated: August 2026

CloudHub 1.0 & 2.0 Architecture: Workers, vCores & Clustering

Deploying and running Mule applications in the cloud requires a thorough understanding of MuleSoft's fully managed integration platform as a service (iPaaS): CloudHub . CloudHub abstracts underlying cloud infrastructure while providing enterprise-grade high availability, dynamic scaling, multi-tenant isolation, and intelligent load balancing. For the Salesforce Certified MuleSoft Developer I exam, mastering worker sizing, scaling patterns, load balancer configurations, and the differences between CloudHub 1.0 and CloudHub 2.0 is essential.

1. CloudHub 1.0 Worker Architecture & Resource Allocation

In CloudHub 1.0, each deployed application runs on one or more dedicated virtual machine instances called Workers . A worker is an isolated Amazon EC2 instance running a single Mule runtime engine JVM on Linux, dedicated exclusively to your application. +-----------------------------------------------------------------------------------------+

  • | CLOUDHUB 1.0 WORKER ARCHITECTURE |
  • | |
  • | +---------------------------------------------------------------------------------+ |
  • | | AWS EC2 INSTANCE (WORKER) | |
  • | | | |
  • | | +-------------------------------------------------------------------------+ | |
  • | | | MULE RUNTIME ENGINE (JVM) | | |
  • | | | | | |
  • | | | +--------------------------+ +--------------------------------+ | | |
  • | | | | ALLOCATED JVM HEAP MEMORY| | JVM METASPACE & NATIVE BUFFERS | | | |
  • | | | | (e.g., 500 MB on 0.1 vC) | | (Operating System & I/O) | | | |
  • | | | +--------------------------+ +--------------------------------+ | | |
  • | | | | | |
  • | | | +-----------------------------------------------------------------+ | | |
  • | | | | DEPLOYED MULE APPLICATION (Flows, Connectors, DataWeave Engine) | | | |
  • | | | +-----------------------------------------------------------------+ | | |
  • | | +-------------------------------------------------------------------------+ | |
  • | | | |
  • | | +-------------------------------------------------------------------------+ | |
  • | | | EPHEMERAL LOCAL STORAGE (8 GB to 328 GB AWS EBS Volume) | | |
  • | | +-------------------------------------------------------------------------+ | |
  • | +---------------------------------------------------------------------------------+ |
  • +-----------------------------------------------------------------------------------------+
  • Worker Sizing & Memory Specifications

When deploying a Mule application to CloudHub 1.0, developers specify the processing capacity and memory of each worker in terms of vCores . Fractional vCores (0.1 and 0.2 vCore) provide cost-effective burstable capacity for lightweight APIs, while multi-vCore sizes provide dedicated compute power for high-throughput batch and streaming workloads.

  • vCore Allocation JVM Heap Memory Total Worker Memory Disk Storage Compute Profile
  • 0.1 vCore 500 MB 1 GB 8 GB Shared CPU with burst credits; ideal for low-volume System APIs
  • 0.2 vCore 1 GB 2 GB 8 GB Shared CPU with burst credits; standard for development/test APIs
  • 1 vCore 2 GB 4 GB 12 GB 1 Dedicated CPU core; standard production baseline for moderate traffic
  • 2 vCores 4 GB 8 GB 40 GB 2 Dedicated CPU cores; high-concurrency Process and Experience APIs
  • 4 vCores 8 GB 16 GB 88 GB 4 Dedicated CPU cores; heavy DataWeave transformations & ETL
  • 8 vCores 16 GB 32 GB 168 GB 8 Dedicated CPU cores; enterprise batch integration workloads
  • 16 vCores 32 GB 64 GB 328 GB 16 Dedicated CPU cores; maximum single-worker compute capacity

Across every worker size, roughly 3 GB of the allocated disk is reserved for the operating system and Mule runtime components , so the smallest 8 GB workers leave about 5 GB for application use (including verbose logging and disk-backed streaming buffers).

CPU Bursting on Fractional Workers

Fractional workers ( 0.1 vCore and 0.2 vCore ) share underlying physical CPU cores with other cloud tenants. CloudHub grants CPU burst credits during idle periods, allowing the application to burst up to 100% of a physical CPU core for short durations (e.g., initial application startup or brief traffic spikes). However, if a fractional worker experiences sustained high CPU utilization, its burst credits deplete, and the hypervisor throttles CPU execution down to the baseline fractional limit (10% or 20%), resulting in elevated latency and potential request timeouts.

Ephemeral vs. Persistent Storage

The local disk attached to a CloudHub worker is ephemeral storage . If a worker restarts, crashes, or is updated during a deployment, all data written to local worker disk storage ( /tmp or local file paths) is permanently lost. To persist state across worker restarts or share data across multiple workers, applications must use Object Store v2 (OSv2) , Anypoint MQ, or external persistent databases.

2. Scaling Strategies: Horizontal vs. Vertical Scaling

To accommodate growing transaction volumes and guarantee high availability (HA), CloudHub provides two complementary scaling dimensions: +-----------------------------------------------------------------------------------------+

  • | HORIZONTAL SCALING vs. VERTICAL SCALING |
  • | |
  • | HORIZONTAL SCALING (Multiple Workers): VERTICAL SCALING (vCore Upsizing): |
  • | +-------------+ +-------------+ +-------------------------------+ |
  • | | Worker 1 | | Worker 2 | | Worker 1 | |
  • | | 0.2 vCore | <---> | 0.2 vCore | | 1.0 or 2.0 vCore | |
  • | | (AZ us-e1a) | | (AZ us-e1b) | | (Larger Heap & Compute) | |
  • | +-------------+ +-------------+ +-------------------------------+ |
  • | \ / | |
  • | v v v |
  • | [HIGH AVAILABILITY & FAILOVER] [LARGE DATAWEAVE HEAP BUFFERS] |
  • | [ROUND-ROBIN LOAD BALANCING] [COMPUTE-INTENSIVE BATCH JOBS] |
  • +-----------------------------------------------------------------------------------------+
  • Horizontal Scaling (Adding Multiple Workers)

High Availability (HA): When you deploy an application with two or more workers , CloudHub automatically distributes them across distinct AWS Availability Zones (AZs) within the selected region. If an entire data center facility or availability zone experiences an outage, surviving workers in peer AZs continue serving traffic without downtime.

Automatic Load Distribution: Inbound HTTP requests arriving at the CloudHub Load Balancer are automatically distributed across all healthy worker instances in round-robin fashion.

Clustering & Object Store Synchronization: When multi-worker applications use Object Store v2 , stored keys and values are synchronized across all workers via a distributed cloud-hosted cache.

Vertical Scaling (Increasing vCore Size)

Expanded JVM Heap Memory: Upgrading from 0.2 vCore (1 GB heap) to 1 vCore (2 GB heap) or 2 vCores (4 GB heap) prevents java.lang.OutOfMemoryError exceptions when processing massive JSON/XML documents or executing complex DataWeave transformations in memory.

Dedicated CPU Compute: Eliminates fractional CPU throttling, ensuring predictable sub-millisecond execution times for compute-heavy cryptographic, compression, or parsing operations.

Horizontal vs. Vertical Sizing Decision Matrix

Requirement / Scenario Recommended Strategy Architectural Rationale

Zero-Downtime SLA / High Availability Horizontal Scaling (2+ Workers) Protects against single-worker crashes and AWS AZ infrastructure failures.

Processing Large 500 MB CSV/XML Files Vertical Scaling (Larger vCore) Provides the physical JVM heap memory required to buffer and transform large datasets.

High Concurrency REST Request Volume Horizontal Scaling (Multiple Workers) Distributes network I/O and HTTP request concurrency across multiple JVM processes.

Batch Jobs with Heavy Parallel Steps Vertical Scaling (2–4 vCores) Provides dedicated CPU cores to execute parallel batch commit threads efficiently.

3. Load Balancing & Traffic Routing: SLB vs. DLB

Every Mule application deployed to CloudHub requires load balancing to route inbound client requests from the public internet or corporate network to the appropriate worker instances. +-----------------------------------------------------------------------------------------+

  • | CLOUDHUB TRAFFIC ROUTING TOPOLOGY |
  • | |
  • | [PUBLIC CLIENT] [ENTERPRISE CLIENT] |
  • | | | |
  • | v v |
  • | +-----------------------------+ +-----------------------------------------------+ |
  • | | SHARED LOAD BALANCER (SLB) | | DEDICATED LOAD BALANCER (DLB) | |
  • | | - app-name.region.cloudhub.io | | - api.enterprise.com (Custom SSL/TLS) | |
  • | | - Ports: 80 -> 8081 | | - URL Mapping Rules: /{app}/ | |
  • | | 443 -> 8082 | | - VPC Internal & Public Routing | |
  • | +-----------------------------+ +-----------------------------------------------+ |
  • | \ / |
  • | +---------------+---------------+ |
  • | | |
  • | v |
  • | +-------------------------------------+ |
  • | | ANYPOINT VPC (10.0.0.0/16) | |
  • | | | |
  • | | +-------------+ +-------------+ | |
  • | | | Worker 1 | | Worker 2 | | |
  • | | | Port: 8081 | | Port: 8081 | | |
  • | | | (AZ-1) | | (AZ-2) | | |
  • | | +-------------+ +-------------+ | |
  • | +-------------------------------------+ |
  • +-----------------------------------------------------------------------------------------+
  • CloudHub Shared Load Balancer (SLB)

Default Routing Infrastructure: Provided automatically in every CloudHub region without additional cost or provisioning.

Domain Naming Convention: Exposes public DNS endpoints following the pattern:

  • http://{app-name}.{region}.cloudhub.io (Standard HTTP)
  • https://{app-name}.{region}.cloudhub.io (Encrypted HTTPS)

Mandatory Port Mappings:

Inbound HTTP on port 80 routes to worker port 8081 .

Inbound HTTPS on port 443 routes to worker port 8082 .

Applications listening on non-standard ports (e.g., 8080, 9090) are unreachable through the SLB.

Direct Worker Addressing:

http://mule-worker-{app-name}.{region}.cloudhub.io:8081 (Bypasses SLB; routes directly to a specific worker over the public internet).

http://mule-worker-internal-{app-name}.{region}.cloudhub.io:8081 (Internal VPC DNS; used for private worker-to-worker communication within an Anypoint VPC).

Anypoint Dedicated Load Balancer (DLB)

Custom Domain Names & SSL Termination: Enables enterprises to map vanity domains (e.g., https://api.acme.com/customers ) to CloudHub applications and manage custom SSL/TLS certificates and cipher suites.

Path-Based URL Mapping Rules: Translates incoming client request paths dynamically to target application names using pattern matching:

  • Input: https://api.acme.com/{app}/{version}/
  • Target App: {app}-{version}
  • Output Path: /

VPC Isolation & Firewall Security: Deployed inside a specific Anypoint Virtual Private Cloud (VPC), allowing internal-only routing over IPsec VPN or AWS Direct Connect while blocking public internet access.

Shared Load Balancer vs. Dedicated Load Balancer Comparison

  • Feature / Capability Shared Load Balancer (SLB) Dedicated Load Balancer (DLB)
  • Domain Names Fixed *.cloudhub.io domain only Custom vanity domains (e.g., api.company.com )

SSL/TLS Certificates Shared MuleSoft wildcard SSL certificate Custom enterprise CA and wildcard TLS certificates

  • mTLS / Two-Way SSL Not supported for client-to-SLB Full support for mutual TLS client authentication
  • URL Path Rewriting No path rewriting (1:1 pass-through) Advanced regex and tokenized URL mapping rules
  • Network Isolation Public internet facing only Deployable in public, private, or internal VPC subnets
  • Cost & Provisioning Included out-of-the-box Requires Anypoint VPC and DLB licensing add-on
  • 4. CloudHub 1.0 vs. CloudHub 2.0 Architecture

CloudHub 2.0 represents the next generation of MuleSoft's managed iPaaS, transitioning from virtual-machine-based infrastructure to a containerized, Kubernetes-based microservices architecture built on Salesforce Hyperforce substrate. +-----------------------------------------------------------------------------------------+

  • | CLOUDHUB 1.0 (EC2 VMs) vs. CLOUDHUB 2.0 (CONTAINERS) |
  • | |
  • | CLOUDHUB 1.0 ARCHITECTURE: CLOUDHUB 2.0 ARCHITECTURE: |
  • | +-------------------------------------+ +-----------------------------------+ |
  • | | ANYPOINT VPC (AWS Subnets) | | PRIVATE SPACE (Hyperforce K8s) | |
  • | | | | | |
  • | | +-----------------------------+ | | +---------------------------+ | |
  • | | | WORKER 1 (Dedicated EC2 VM) | | | | INGRESS CONTROLLER (TLS) | | |
  • | | | - Mule Runtime JVM | | | +---------------------------+ | |
  • | | | - Linux OS + Virtual Disk | | | | | |
  • | | +-----------------------------+ | | v | |
  • | | | | +---------------------------+ | |
  • | | +-----------------------------+ | | | REPLICA 1 (K8s Pod/CGroup)| | |
  • | | | WORKER 2 (Dedicated EC2 VM) | | | | - Lightweight Container | | |
  • | | | - Mule Runtime JVM | | | | - Rapid Spin-up (~30s) | | |
  • | | +-----------------------------+ | | +---------------------------+ | |
  • | +-------------------------------------+ +-----------------------------------+ |
  • +-----------------------------------------------------------------------------------------+
  • Shared Spaces vs. Private Spaces in CloudHub 2.0

Shared Spaces: Multi-tenant container environments managed by MuleSoft across 12+ global regions. Suitable for lightweight public APIs that do not require private corporate network connectivity.

Private Spaces: Virtual, isolated private network partitions (analogous to an Anypoint VPC + DLB in CloudHub 1.0). Provides built-in ingress load balancing, custom domain management, and out-of-the-box connectivity to corporate data centers via Anypoint VPN or AWS Transit Gateway .

Replicas vs. Workers

In CloudHub 2.0, the unit of execution is a Replica (a containerized Kubernetes pod) rather than a VM worker. Replicas start up in seconds (compared to 3–5 minutes for CloudHub 1.0 EC2 instances), consume fewer cloud resources, and support fine-grained replica allocations:

Replica Sizes: 0.1, 0.2, 0.5, 1.0, 1.5, 2.0, 2.5, 3.0, 3.5, and 4.0 replicas.

Comprehensive Comparison: CloudHub 1.0 vs. CloudHub 2.0

  • Architectural Dimension CloudHub 1.0 CloudHub 2.0
  • Underlying Substrate AWS EC2 Virtual Machines Containerized Kubernetes on Salesforce Hyperforce
  • Execution Unit Worker (VM instance) Replica (Container Pod)

Private Network Construct Anypoint VPC + VPN / Direct Connect Private Space with integrated VPN / Transit Gateway

  • Load Balancing Mechanism Shared Load Balancer (SLB) or DLB Built-in Ingress Controller per Private Space
  • Deployment Speed 3 to 6 minutes (EC2 provisioning) 30 to 90 seconds (Container scheduling)
  • Custom Domains Requires Dedicated Load Balancer (DLB) Built directly into Private Space Ingress configuration
  • HTTP Listener Ports Port 8081 (HTTP) / 8082 (HTTPS) Port 8081 (HTTP) across all deployments
  • 5. Static IP Allocation & Outbound Whitelisting

When Mule applications connect to secured external partner systems or corporate databases protected by network firewalls, the receiving firewall must whitelist the IP addresses of the Mule workers.

Static IPs in CloudHub 1.0

By default, CloudHub assigns dynamic public IP addresses that change whenever an application restarts, redeploys, or experiences worker recovery.

In Runtime Manager, administrators can enable Allocate Static IP for an application. CloudHub assigns a fixed, static IP address from the organization's static IP pool to each worker.

Zero-Downtime Static IP Swapping: During a rolling update, CloudHub provisions a temporary IP for the new worker during verification, and seamlessly swaps the permanent static IP to the new worker upon cutover, ensuring uninterrupted communication with downstream firewalls.

Egress IPs in CloudHub 2.0

In CloudHub 2.0 Private Spaces , outbound traffic routes through deterministic Egress IP addresses associated with the Private Space's NAT gateway, eliminating the need to manage individual IP addresses per replica.

6. Exam Watch: Core CloudHub Architecture Scenarios

Important

HTTP Listener Port Requirements in CloudHub 1.0 Always configure the HTTP Listener in your Mule application using dynamic property placeholders:

  • port="${http.port}" (resolves to 8081 at runtime)
  • port="${https.port}" (resolves to 8082 at runtime)

If you hardcode port 8080 or 80 , the application will start locally in Studio but fail to receive traffic when deployed behind the CloudHub Shared Load Balancer.

Warning

Fractional Worker CPU Throttling 0.1 and 0.2 vCore workers rely on CPU burst credits. For high-volume production integrations or batch processes, deploying fractional workers risks severe CPU throttling. Use at least 1.0 vCore for high-load production workloads.

Tip

High Availability Requirement To achieve High Availability (HA) on the MuleSoft Developer I exam, always select at least two workers deployed in different availability zones. A single worker—regardless of how many vCores are assigned—represents a single point of failure.