A Dapr state store component provides key-value state management through Dapr APIs while hiding the underlying storage system from application code. Applications can store and read data through HTTP or gRPC requests, regardless of the programming language used. section 7.3.3 section 7.3.2
On Kubernetes, a component resource configures the backing implementation, such as Redis. The daprd sidecar reads that configuration and connects to the store, while the application calls a local API. Replacing local Redis with managed Redis therefore requires configuration changes rather than application-code or dependency changes. section 7.3.2 section 7.3.2
A typical integration follows these steps:
- Define a Dapr Component resource with a state implementation, such as state.redis, its host, and secret references. section 7.3.2
- Make the component available in the cluster so daprd can load its configuration and connect to the backing store. section 7.3.2
- Call the state API with a store name and key, using an HTTP or gRPC client or an optional Dapr SDK. section 7.3.3
Reading and writing state
With a store named statestore, POST a JSON state entry to http://localhost:3500/v1.0/state/statestore, then read it with GET at http://localhost:3500/v1.0/state/statestore/name. The Dapr SDK exposes equivalent GetState and SaveState operations.
In the Conference application, the Agenda service can remove its direct Redis dependency by using the Statestore APIs. Adoption remains selective: the Call for Proposals service can retain PostgreSQL when it needs SQL and PostgreSQL-specific features. section 7.3.5 section 7.3.5
