Stateful components backed by object stores
Which Mule components keep state in an object store (aggregators, the Idempotent Message Validator, redelivery policies, the Cache scope, watermarks and batch jobs), what their default stores do, and how to configure the store so the state survives restarts and is shared across CloudHub 2.0 replicas.
Design Mule applications and integration solutions using stateful components that may be configured with an OS.
~7 min read · 8 practice questions
What the exam expects
- Identify which components store state in an object store and what each default store keeps, for how long, and whether it survives a restart.
- Size aggregator state so object store throughput stays low.
- Configure the Idempotent Message Validator's ID and store, and a redelivery policy's counter store, for the traffic pattern.
- Design a Cache scope strategy that survives restarts, and plan a Mule 4.13 upgrade and rollback for cached data.
- Keep watermarks, schedulers, idempotency keys and batch state correct across CloudHub 2.0 replicas.
Stateful component: a filter, router or processor that stores state between messages in an object store (Object stores). Idempotent Message Validator: lets only messages with a unique ID continue (Idempotent Message Validator). Redelivery policy: a source filter that limits how often a failing message is executed (Redelivery Policy). Caching strategy: the actions and object store a Cache scope uses (Cache Scope).
Key facts
- Detail
- Persistent, always available
- Detail
#[correlationId]
- Detail
- Not used; no effect
- Detail
- Nonpersistent, entryTtl 300 s
- Detail
- 5
- Detail
- Stored in an object store, polled every second
- Detail
- In-memory object store
- Detail
- Strategy's object store shared across all nodes
- Detail
- Clear the caching strategy's object store first
- Detail
- Primary replica only when clustered
- Detail
- Object Store v2 by default
Sources for this section (7)
- Object storesdocs.mulesoft.com (opens in a new tab)
- Idempotent Message Validatordocs.mulesoft.com (opens in a new tab)
- Redelivery Policydocs.mulesoft.com (opens in a new tab)
- Aggregators referencedocs.mulesoft.com (opens in a new tab)
- Cache Scopedocs.mulesoft.com (opens in a new tab)
- Caching strategydocs.mulesoft.com (opens in a new tab)
- Compare CloudHub and CloudHub 2.0docs.mulesoft.com (opens in a new tab)
- Why must a caching strategy's Key Expression produce the same key for two equal requests?
- When a CloudHub 2.0 application runs a single replica without clustering, what can happen to a scheduled run?
- Which feature flag controls whether the Cache scope persists only the message instead of the full event?
- What happens to a running CloudHub 2.0 batch job when Mule restarts within the same deployment?
The questions are free to read. Answers with their sources and self-grading are included with the pack.
Keep reading with the MuleSoft Platform Integration Architect pack
- Core concepts
- Exam traps
- Worked scenario
The pack includes:
- All 40 lessons of the MuleSoft Platform Integration Architect guide, with reading progress
- Interactive decision walks and step-by-step sequence steppers
- Practice exams purchase adds inline bank questions and topic practice (8 questions for this lesson)
- An official source cited for every claim
- An AI tutor that answers from the guide
- Choose guide-only, practice-only, or save $4 with both