MuleSoft Solution Architecture Fundamentals (Course #architecture-fundamentals)
For solution architects (new to MuleSoft).
By the end, you can
By the end of this course, you will be able to design a complete API-led reference architecture — layers, topology, security, sizing — so that the first release holds its p99, availability and budget targets.
Running case study
Terravia Group, an industrial-equipment maker in 14 countries, runs 320 point-to-point flows between SAP ECC, a WMS and legacy EDI; global ERP consolidation starts in 12 months. The board requires 99.9 % availability on order flows, p99 under 500 ms, and a runtime budget capped at 24 vCores for year one. Your architecture must survive both the migration and the audit.
Programme every line is something you do
6 modules · 18 topics · in course-flow order
-
Module 1
Boundaries Before Blueprints
Objective. Design the System/Process/Experience split for Terravia's estate and set principles enforceable at architecture review.
- Apply the three-layer model to the SAP ECC → order orchestration → partner portal chain, naming each API's single responsibility
- Assign responsibilities per layer: System APIs wrap SAP BAPI/IDoc, Process APIs own orchestration, Experience APIs shape UI payloads
- Set reuse-driving principles with metrics: canonical schemas as RAML 1.0 fragments, one source of truth per master object
-
Module 2
Hybrid, Cloud or On-Prem?
Objective. Evaluate hybrid, cloud and on-prem trade-offs and commit to a network topology that reaches plant-floor systems safely.
- Compare hybrid, cloud and on-prem patterns on latency, data residency and ops maturity in a weighted matrix, e.g. residency at 40 %
- Match the pattern to constraints: site-to-site VPN or dedicated interconnect, static egress IPs for partner allow-lists
- Sketch the topology end to end — Anypoint VPC with CIDR sizing (e.g. /24), VPN to on-prem, load balancers — on one diagram
-
Module 3
One Tool, One Concern
Objective. Map each Anypoint component to the concern it owns and settle tool ownership between platform and product teams.
- Map Runtime Manager (run), API Manager (govern), Exchange (reuse), Design Center (design) to lifecycle stages and RACI lines
- Split ownership: the platform team administers API Manager policies and environments; squads own their Design Center projects
- Trace one integration spec-first: RAML 1.0 in Design Center → mocking service → scaffolding in Studio → deploy via Runtime Manager
-
Module 4
Defense in Depth, by Policy
Objective. Secure every exposure point with edge-applied policies and select the OAuth 2.0 flow fitting each consumer profile.
- Layer controls where they belong: TLS 1.3 termination at the edge, client-enforcement and throttling policies in API Manager
- Choose OAuth 2.0 flows per scenario: client credentials for M2M, authorization code + PKCE for mobile and SPA front ends
- Plan encryption at rest and in transit: JCE/PGP for sensitive payloads, secure properties for secrets, 90-day key rotation
-
Module 5
Right-Size the Runtime
Objective. Size workers, clusters and hosting mode to hold 99.9 % availability within a 24-vCore year-one envelope, evidence in hand.
- Compare CloudHub, Runtime Fabric and customer-hosted on control granularity, startup time and infra cost per vCore
- Size for the workload: 2 × 0.5-vCore workers per critical API on CloudHub, RTF autoscaling at 70 % CPU, Anypoint MQ absorbing bursts
- Walk failure scenarios: zone loss with two workers, retries with exponential backoff + jitter, Anypoint MQ DLQ, RTO under 15 min
-
Module 6
Design Review: Defend the Blueprint
Objective. Defend your Terravia target architecture before a review board that scores every trade-off against the NFRs.
- Present the three-layer topology against Terravia's numbers: p99 < 500 ms, 99.9% availability, 24-vCore year-1 ceiling
- Answer live challenges — shared vs dedicated runtimes, VPC sizing, build-vs-reuse — with figures, not adjectives
- Turn review findings into a prioritized backlog scored by risk retired per architect-day invested
References & Official Documentation every claim above has a source
Module 1
- Considerations for Simplifying Accelerator AssetsMuleSoft Docs
Module 2
- CloudHub 2.0 Networking: Private Spaces, CIDR and VPNMuleSoft Docs
- Deployment OptionsMuleSoft Docs
Module 3
- Anypoint Platform Hosting OverviewMuleSoft Docs
Module 4
- RFC 7636 — Proof Key for Code Exchange by OAuth Public ClientsSpecification
- Gateway Policies in API ManagerMuleSoft Docs
Module 5
- Allocating Resources for Application Deployment on Runtime FabricMuleSoft Docs
- CloudHub 2.0 ArchitectureMuleSoft Docs