# Stateful components backed by object stores

*MuleSoft Platform Integration Architect Study Guide · Designing integration solutions to meet persistence requirements · Last updated November 13, 2026 · https://www.certifyforce.com/study-guide/mulesoft-platform-integration-architect/designing-integration-solutions-to-meet-persistence-requirements/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.

- Certification: Salesforce MuleSoft Platform Integration Architect
- Exam section: Designing integration solutions to meet persistence requirements
- Study guide: https://www.certifyforce.com/study-guide/mulesoft-platform-integration-architect

**Official exam objective:**

> Design Mule applications and integration solutions using stateful components that may be configured with an OS.

## 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](https://docs.mulesoft.com/mule-runtime/latest/mule-object-stores)). **Idempotent Message Validator:** lets only messages with a unique ID continue ([Idempotent Message Validator](https://docs.mulesoft.com/mule-runtime/latest/idempotent-message-validator)). **Redelivery policy:** a source filter that limits how often a failing message is executed ([Redelivery Policy](https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy)). **Caching strategy:** the actions and object store a Cache scope uses ([Cache Scope](https://docs.mulesoft.com/mule-runtime/latest/cache-scope)).

## Key facts

| Fact | Detail | Source |
|---|---|---|
| App default store | Persistent, always available | [Object stores](https://docs.mulesoft.com/mule-runtime/latest/mule-object-stores) |
| Validator ID default | `#[correlationId]` | [Idempotent Message Validator](https://docs.mulesoft.com/mule-runtime/latest/idempotent-message-validator) |
| Validator Value Expression | Not used; no effect | [Idempotent Message Validator](https://docs.mulesoft.com/mule-runtime/latest/idempotent-message-validator) |
| Redelivery store default | Nonpersistent, entryTtl 300 s | [Redelivery Policy](https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy) |
| Max Redelivery Count default | 5 | [Redelivery Policy](https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy) |
| Aggregator state | Stored in an object store, polled every second | [Aggregators reference](https://docs.mulesoft.com/aggregators-module/latest/aggregators-module-reference) |
| Cache default strategy | In-memory object store | [Cache Scope](https://docs.mulesoft.com/mule-runtime/latest/cache-scope) |
| Cache in a cluster | Strategy's object store shared across all nodes | [Cache Scope](https://docs.mulesoft.com/mule-runtime/latest/cache-scope) |
| Rollback from 4.13 | Clear the caching strategy's object store first | [Caching strategy](https://docs.mulesoft.com/mule-runtime/latest/cache-scope-strategy) |
| CloudHub 2.0 schedulers | Primary replica only when clustered | [Compare CloudHub and CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/ch2-migration-comparison) |
| CloudHub 2.0 batch | Object Store v2 by default | [Compare CloudHub and CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/ch2-migration-comparison) |

## Check yourself

- 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?

## Sources

- [Store Application Data Using Object Stores](https://docs.mulesoft.com/mule-runtime/latest/mule-object-stores)
- [Object Store Connector](https://docs.mulesoft.com/object-store-connector/latest/)
- [Aggregators Module Reference 1.1](https://docs.mulesoft.com/aggregators-module/latest/aggregators-module-reference)
- [Idempotent Message Validator](https://docs.mulesoft.com/mule-runtime/latest/idempotent-message-validator)
- [Configure a Redelivery Policy](https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy)
- [Cache Scope](https://docs.mulesoft.com/mule-runtime/latest/cache-scope)
- [Set Up a Caching Strategy](https://docs.mulesoft.com/mule-runtime/latest/cache-scope-strategy)
- [Clustering](https://docs.mulesoft.com/cloudhub-2/ch2-clustering)
- [Compare CloudHub and CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/ch2-migration-comparison)

## About the full unit

The "Core concepts", "Exam traps" and "Worked scenario" sections of this unit, its 8 linked practice questions, and unlimited timed mock exams are included with the MuleSoft Platform Integration Architect pack (USD $19): https://www.certifyforce.com/practice-exams