In Part 2, we got Dapr running locally and saw how the sidecar fits into a normal development workflow. Now we can start using Dapr for real work and state management is usually the first building block teams adopt.

State is one of the earliest places where infrastructure concerns leak into application code. Even simple services end up tightly coupled to a specific database client, connection logic, retry behavior, and environment‑specific configuration. Dapr’s state API is designed to remove that coupling by providing a consistent abstraction over state, regardless of the backing store.

This post walks through how Dapr handles state using Redis and Postgres, why this abstraction works well in real systems, and how to use it in both Go and .NET.

Why Traditional State Access Becomes a Problem

Most applications interact with state using vendor‑specific SDKs. That works at first, but over time it introduces friction:

• Switching from Redis to Postgres requires code changes
• Local development often uses a different store than production
• Each service implements its own retry and error handling
• Testing requires mocking database clients
• Polyglot teams duplicate the same logic in multiple languages
• As systems grow, these concerns multiply across services and environments

Dapr’s state building block exists to eliminate this entire class of coupling

Dapr’s State Management Model

Dapr exposes a simple key/value state API over HTTP or gRPC.

Your application:

• Saves state by key
• Retrieves state by key
• Deletes state by key

It does not know:

• Which database is being used
• How connections are managed
• How retries or consistency are handled
• How serialization works
• How secrets are stored

Those details live in a state store component, defined outside of your application code.

Architecture Overview

At runtime, state access looks like this:

Application → Dapr State API → State Store (Redis / Postgres / etc.)

Your application talks only to the local Dapr sidecar. Dapr handles communication with the configured state store.

This separation allows you to change the backing store without touching application code.

Saving and Retrieving State

From the application’s perspective, state operations are straightforward.

Typical operations include:

• Saving an object under a key
• Retrieving it later
• Updating or deleting it

The same API works whether the backing store is Redis, Postgres, Cosmos DB, DynamoDB, or something else.

This is especially useful in polyglot environments, where different services are written in different languages but share the same state access patterns.

Configuring a Redis State Store

Before writing any application code, you define a Dapr state store component.

Redis state store component

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: statestore
spec:
  type: state.redis
  version: v1
  metadata:
    - name: redisHost
      value: localhost:6379
    - name: redisPassword
      value: ""

A few important notes:

• You can restrict components to specific apps using scopes:
• Secrets should be stored in a secret store component, not inline
• In local mode, components load at startup (no hot‑reload)
• In Kubernetes, components can be updated dynamically

Once this component is in place, any service using Dapr can access Redis state via the statestore name.

No code changes are required if you later swap Redis for Postgres

Go Example: Saving and Retrieving State

In Go, using the official Dapr SDK.

Saving state

package main

import (
	"context"
	"encoding/json"
	"fmt"

	"github.com/dapr/go-sdk/client"
)

type Order struct {
	Id string `json:"id"`
	Amount  int    `json:"amount"`
}

func main() {
	ctx := context.Background()
	daprClient, _ := client.NewClient()
	order := Order{Id: "order-123", Amount: 100}
	saveOrder(ctx, daprClient, order)

	retrievedOrder, _ := getOrder(ctx, daprClient, order.Id)

	fmt.Printf("%s - %d", retrievedOrder.Id, retrievedOrder.Amount)
}

func saveOrder(ctx context.Context, daprClient client.Client, order Order) error {
	orderData, err := json.Marshal(order)
	if err != nil {
		return err
	}
	return daprClient.SaveState(ctx, "statestore", order.Id, orderData, nil)
}

Retrieving state

func getOrder(ctx context.Context, daprClient client.Client, orderID string) (*Order, error) {
	result, err := daprClient.GetState(ctx, "statestore", orderID, nil)
	if err != nil {
		return nil, err
	}

	if result.Value == nil {
		return nil, nil // Order not found
	}

	var order Order
	if err := json.Unmarshal(result.Value, &order); err != nil {
		return nil, err
	}

	return &order, nil
}

There is no Redis client, no connection string, and no retry logic in the application code. Dapr handles all of that.

.NET Example: Saving and Retrieving State

In .NET, using the official Dapr SDK.

Saving state

using Dapr.Client;
var client = new DaprClientBuilder().Build();

var order = new Order("order-123",100);
 
await client.SaveStateAsync(
    "statestore",
    order.Id,
    order
);

public record Order(string Id, int Amount);

Retrieving state

var order_received = await client.GetStateAsync<Order>(
    "statestore",
    "order-123"
);

Again, the application code has no knowledge of Redis, Postgres, or any other backing store.

Using Dapr Without an SDK (Optional)

You don’t need to use a language‑specific SDK to work with Dapr. Every building block is ultimately exposed through simple HTTP endpoints on the local sidecar. This is useful when:

• your language doesn’t have an official SDK
• you want to minimize dependencies
• you’re debugging or testing behavior directly

The examples below show the same state operations using plain curl against the Dapr sidecar (default port 3500):

curl -X POST http://localhost:3500/v1.0/state/statestore \
  -H "Content-Type: application/json" \
  -d '[ { "key": "order-123", "value": { "id": "order-123", "amount": 100 } } ]'

curl http://localhost:3500/v1.0/state/statestore/order-123

These raw HTTP calls are exactly what the Go and .NET SDKs generate under the hood.

Switching to Postgres Without Code Changes

To switch from Redis to Postgres, the application code stays exactly the same. Only the component configuration changes.

Postgres state store component

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: statestore
spec:
  type: state.postgresql
  version: v1
  metadata:
    - name: connectionString
      value: "host=localhost user=postgres password=postgres dbname=dapr"

From the application’s perspective:

• The API is unchanged
• The state store name is unchanged
• No redeploy is required beyond configuration

This is one of the most practical benefits of Dapr in real systems.

Additional Features You Should Know About

Dapr’s state API includes several capabilities that go beyond simple key/value access.

Optimistic concurrency (ETags)

Dapr supports ETags to prevent lost updates.

Transactional state operations

You can save multiple keys atomically.

Consistency modes

State stores can define:

• strong consistency
• eventual consistency

TTL (time‑to‑live)

Some state stores support per‑key expiration.

These features become important as systems grow.

Why This Matters in Practice

Using Dapr for state management enables:

• Infrastructure portability – swap Redis for Postgres without rewriting services
• Environment parity – local, staging, and production behave consistently
• Simpler testing – state access can be tested via HTTP
• Cleaner codebases – business logic stays separate from infrastructure concerns

This is especially valuable in polyglot or multi‑team environments.

Limitations to Keep in Mind

Dapr’s state API is intentionally simple. It works best for:

• Service‑owned state
• Event‑driven workflows
• Key/value access patterns

It is not a replacement for:

• Complex relational queries
• Reporting or analytics workloads
• Heavy analytical use cases

Many systems use Dapr for service state while still accessing databases directly for read‑heavy or query‑driven workloads.

What’s Next

Now that we can store and retrieve state, we can move on to one of the most powerful parts of Dapr: Publish and Subscribe.

In the next post, we’ll explore:

• Publishing events without broker‑specific SDKs
• Subscribing to messages using HTTP endpoints
• Switching between Kafka, RabbitMQ, and Azure Service Bus via configuration

This is where Dapr really starts to shine in event‑driven systems.