Building microservices is hard.

Microservices don't just come with scalability, they come with mandatory complexity you pay for upfront and forever.

You need to handle service-to-service communication, message brokers, state management, secrets, and more. Each of these concerns requires its own library, configuration, and expertise.

What if there were a runtime that provided all these capabilities out of the box, regardless of the infrastructure you use?

That is exactly what Dapr does.

Dapr (Distributed Application Runtime) is a portable, event-driven runtime that makes it easier to build resilient microservices. It provides a set of building block APIs for common distributed systems challenges: pub/sub messaging, service invocation, state management, secrets, and more.

The best part? Dapr is infrastructure-agnostic. You can swap RabbitMQ for Kafka, or Redis for PostgreSQL, without changing a single line of application code.

Dapr is a free and open-source project; you can see its GitHub repo here.

And when you combine Dapr with .NET Aspire, you get a powerful local development experience where containers, sidecars, and services are orchestrated for you with a single command.

In this post, we will explore:

• What is Dapr and How It Simplifies Microservice Development?
• Understanding Dapr Building Blocks
• How Dapr Components Work
• How to set up Dapr with .NET Aspire
• How to use Dapr to Publish Events to a Message Queue with Pub/Sub
• How to use Dapr to Consume Events from a Message Queue
• How to use Dapr to Call REST Services with Service Invocation
• How to use Dapr to Manage State with State Management

Let's dive in.

When you build microservices, you quickly face a set of recurring challenges:

• How do services discover and call each other reliably?
• How do you publish and consume events across services?
• How do you store state without coupling to a specific database?
• How do you manage secrets securely?
• How do you handle retries, timeouts, and circuit breakers?

Without Dapr, you solve each problem independently. You install a RabbitMQ client library for messaging, a Redis library for caching, a Vault client for secrets, and write custom retry logic. Each library has its own API, configuration, and behavior.

You can use messaging libraries such as MassTransit, Wolverine, Rebus or Brighter, but they solve only the async messaging flows. You still need to implement caching, secrets, synchronous communication, service discovery, and others.

Dapr solves all of these by providing a unified set of APIs that abstract these concerns. Your application talks to Dapr, and Dapr talks to the infrastructure.

If you need to switch from RabbitMQ to Kafka for messaging, you change a configuration file (in production). Your application code stays exactly the same.

Dapr runs as a sidecar alongside your application. This means Dapr is a separate process (or container) that runs next to your service.

Your application communicates with the Dapr sidecar over HTTP or gRPC on localhost. The sidecar handles the actual interaction with external infrastructure: message brokers, databases, secret stores, and other services.

Here is how it works:

In a Kubernetes environment, Dapr runs as a companion container within the same pod as your application. In local development, it runs as a separate process on your machine.

This sidecar architecture provides several benefits:

1. Language agnostic: Dapr works with any language that can make HTTP or gRPC calls. Whether you write in C#, Go, Python, or Java, you use the same Dapr APIs.

2. No SDK lock-in: While Dapr provides SDKs for popular languages (including .NET), you can always fall back to raw HTTP calls.

3. Independent lifecycle: Your application and the Dapr sidecar can be updated independently. Upgrading Dapr does not require recompiling your application.

4. Consistent behavior: Retry policies, timeouts, and circuit breakers are configured at the sidecar level. Every service in your system automatically receives the same resilience guarantees.

Each service in your system has its own Dapr sidecar. When Service A wants to call Service B, it tells its local Dapr sidecar. The sidecar handles service discovery, routes the request to Service B's sidecar, which then forwards it to Service B.

This means your services never communicate directly with each other. All communication goes through the Dapr sidecars, which gives you observability, security, and resilience for free.

What about an overhead when talking to the sidecar on each request? This overhead is minimal, as all requests are done on the localhost.

And the benefits you get outpass this small disadvantage.

Dapr organizes its capabilities into building blocks. Each building block is an independent API that addresses a specific challenge in distributed systems.

You can use any combination of building blocks.

Here are the main building blocks:

Enables services to call each other reliably. Dapr handles service discovery, retries, and distributed tracing automatically.

Instead of hardcoding URLs or using a service registry, you reference services by their App ID:

csharp
1// Call the "hotels-api" service via Dapr
2var rooms = await daprClient.InvokeMethodAsync<RoomAvailabilityResponse>(
3    HttpMethod.Get,
4    "hotels-api",
5    "hotels/1/rooms/available");

Dapr resolves the address of hotels-api service, routes the request through the sidecar network, and returns the response. If the target service is temporarily unavailable, Dapr can retry the request based on your configured policies.

Allows services to communicate asynchronously through queues and topics. Publishers send events to a topic, and subscribers receive them.

The pub/sub building block supports at-least-once delivery guarantees. It works with any supported message broker: RabbitMQ, Kafka, Azure Service Bus, Redis Streams, and more.

csharp
1await daprClient.PublishEventAsync("pubsub", "booking-created", bookingEvent);

Subscribers receive events through HTTP endpoints that Dapr calls automatically:

csharp
1app.MapPost("/dapr/booking-created",
2    [Topic("pubsub", "booking-created")]
3    async (BookingCreatedEvent message) =>
4    {
5        // Process the event
6        return Results.Ok();
7    });

This model is fundamentally different from traditional background service consumers. Dapper Sidecar subscribes to a message queue, receives your message and pushes it to your application via HTTP POST requests.

Provides key/value state storage with pluggable backends. You can use Redis, PostgreSQL, MongoDB, Azure Cosmos DB, or any other supported state store.

csharp
1// Save state
2await daprClient.SaveStateAsync("statestore", "user-123", userData);
3
4// Get state
5var user = await daprClient.GetStateAsync<UserData>("statestore", "user-123");
6
7// Delete state
8await daprClient.DeleteStateAsync("statestore", "user-123");

The state management building block also supports:

• Concurrency control with ETags for optimistic locking
• TTL (Time-to-Live) for automatic expiration
• Transactions for atomic operations across multiple keys

Retrieves secrets from various secret stores without hardcoding credentials in your application. Supported stores include Azure Key Vault, AWS Secrets Manager, HashiCorp Vault, Kubernetes secrets, and local file-based stores.

csharp
1var secrets = await daprClient.GetSecretAsync("secretstore", "payment-gateway");
2var apiKey = secrets["api-key"];

Creates connections to external systems. Input bindings trigger your application when an external event occurs. Output bindings let your application invoke external systems.

For example, you can use an output binding to write files to local storage, send emails, or trigger a cloud function:

csharp
1await daprClient.InvokeBindingAsync("email-output", "create", emailContent);

Provides mutual exclusion for scenarios where multiple service instances might access the same resource concurrently:

csharp
1var lockResponse = await daprClient.Lock(
2    "statestore", "room-lock:101", "owner-id", expiryInSeconds: 30);
3
4if (lockResponse.Success)
5{
6    // Exclusive access to the resource
7    await daprClient.Unlock("statestore", "room-lock:101", "owner-id");
8}

Dapr also provides building blocks for:

• Workflows: Long-running, persistent processes that span multiple services
• Actors: Virtual actor model for stateful computations with single-threaded execution
• Configuration: Dynamic application configuration retrieval and subscription
• Cryptography: Encryption and decryption operations
• Jobs: Scheduled and triggered batch processing

Building blocks define what Dapr can do: pub/sub, state management, secrets, and so on.

Components define how Dapr does it: which specific technology implements each building block.

Think of it this way:

• The pub/sub building block is the API your application calls
• A pub/sub component (like RabbitMQ or Kafka) is the actual message broker behind that API

This separation is what makes Dapr infrastructure-agnostic. Your application code uses the building block API. The component configuration determines which technology fulfills the request.

Components are configured using YAML files. Each file specifies the component type, version, and connection metadata.

Here is an example of a RabbitMQ pub/sub component:

yaml
1apiVersion: dapr.io/v1alpha1
2kind: Component
3metadata:
4  name: pubsub
5spec:
6  type: pubsub.rabbitmq
7  version: v1
8  metadata:
9    - name: connectionString
10      value: "amqp://guest:guest@localhost:5672"
11    - name: durable
12      value: "true"
13    - name: autoAck
14      value: "false"

And here is a PostgreSQL state store component:

yaml
1apiVersion: dapr.io/v1alpha1
2kind: Component
3metadata:
4  name: statestore
5spec:
6  type: state.postgresql
7  version: v1
8  metadata:
9    - name: connectionString
10      value: "host=localhost;port=5432;username=postgres;password=postgres;database=dapr_state"

The metadata.name field is the identifier you use in your application code.

• When you call daprClient.PublishEventAsync("pubsub", ...), Dapr looks for a component named pubsub.
• When you call daprClient.SaveStateAsync("statestore", ...), it uses the component named statestore.

To switch from RabbitMQ to Kafka, you change only the YAML file:

yaml
1apiVersion: dapr.io/v1alpha1
2kind: Component
3metadata:
4  name: pubsub
5spec:
6  type: pubsub.kafka
7  version: v1
8  metadata:
9    - name: brokers
10      value: "localhost:9092"

Your application code remains identical. The pubsub name in your code maps to whatever component is configured, regardless of the underlying technology.

This is one of Dapr's most powerful features. You can use different tools in development and in production.

In development, you might use RabbitMQ and a local file-based secret store. In production, you switch to Azure Service Bus and Azure Key Vault by changing the component YAML files.

.NET Aspire is an application framework for building observable, production-ready, cloud-native applications. It handles service orchestration, configuration, health checks, and telemetry out of the box.

When you combine Aspire with Dapr, Aspire manages the lifecycle of Dapr sidecars alongside your services. Each service gets a Dapr sidecar automatically, and the Aspire dashboard shows both your services and their sidecars.

Before getting started, you need:

• .NET 10 SDK installed
• Docker Desktop or Podman running
• Dapr CLI installed and initialized

Install the Dapr CLI, follow the instructions on the official website for your target OS.

Install Aspire templates and CLI:

bash
1dotnet new install Aspire.ProjectTemplates
2dotnet tool install --global aspire.cli

The AppHost project is the orchestrator that defines your application's architecture and dependencies.

Create a new Aspire AppHost project and install the required NuGet packages:

bash
1dotnet add package CommunityToolkit.Aspire.Hosting.Dapr
2dotnet add package Aspire.Hosting.PostgreSQL

Note: The Aspire.Hosting.Dapr package from Microsoft is limited to version 9.1.0. Use the CommunityToolkit.Aspire.Hosting.Dapr package, which is actively maintained and supports Aspire 13+.

Here is how to configure the AppHost with Dapr sidecars:

csharp
1using CommunityToolkit.Aspire.Hosting.Dapr;
2using Microsoft.Extensions.Hosting;
3
4var builder = DistributedApplication.CreateBuilder(args);
5
6// Infrastructure
7var postgres = builder.AddPostgres("postgres")
8    .WithDataVolume(isReadOnly: false);
9
10// Dapr components path
11var daprComponentsPath = Path.Combine("..", "dapr", "components");
12
13// Hotels Service with Dapr sidecar
14var hotelsApi = builder.AddProject<Projects.Hotels_Api>("hotels-api")
15    .WithReference(postgres)
16    .WithDaprSidecar(new DaprSidecarOptions
17    {
18        AppId = "hotels-api",
19        ResourcesPaths = [daprComponentsPath]
20    })
21    .WithExternalHttpEndpoints();
22
23// Bookings Service with Dapr sidecar
24var bookingsApi = builder.AddProject<Projects.Bookings_Api>("bookings-api")
25    .WithReference(postgres)
26    .WithReference(hotelsApi)
27    .WithDaprSidecar(new DaprSidecarOptions
28    {
29        AppId = "bookings-api",
30        ResourcesPaths = [daprComponentsPath]
31    })
32    .WithExternalHttpEndpoints();
33
34builder.Build().Run();

Each call to WithDaprSidecar() creates a Dapr sidecar process for the service. The AppId uniquely identifies the service in the Dapr ecosystem. The ResourcesPaths points to the folder containing your Dapr component YAML files.

When you run the AppHost, Aspire:

1. Starts PostgreSQL
2. Launches each service with its configured Dapr sidecar
3. Opens the Aspire dashboard in your browser

The Aspire dashboard shows all running services, their Dapr sidecars, health status, logs, and distributed traces.

Now let's see how to actually use Dapr's SDK to implement communication between services.

Add the Dapr SDK to your service project:

bash
1dotnet add package Dapr.AspNetCore

Register DaprClient in the DI container:

csharp
1var builder = WebApplication.CreateBuilder(args);
2
3builder.Services.AddDaprClient();
4
5var app = builder.Build();
6
7// Required for Dapr pub/sub
8app.UseCloudEvents();
9app.MapSubscribeHandler();
10
11await app.RunAsync();

UseCloudEvents() enables parsing of the CloudEvents envelope that Dapr wraps around pub/sub messages. MapSubscribeHandler() exposes a /dapr/subscribe endpoint that Dapr calls to discover which topics your service subscribes to.

To publish an event, inject DaprClient and call PublishEventAsync:

csharp
1public class CreateBookingHandler(DaprClient daprClient)
2{
3    public async Task HandleAsync(CancellationToken cancellationToken = default)
4    {
5        var createdEvent = new BookingCreatedEvent(
6            BookingId: bookingId,
7            GuestName: request.GuestName,
8            HotelId: request.HotelId,
9            RoomId: request.RoomId,
10            TotalPrice: totalPrice,
11            Timestamp: DateTime.UtcNow);
12        
13        await daprClient.PublishEventAsync("pubsub", "booking-created", createdEvent, cancellationToken);
14    }
15}

Dapr delivers pub/sub messages by calling HTTP POST endpoints on your service. You declare subscriptions using the [Topic] attribute:

csharp
1using Carter;
2using Dapr;
3
4public class BookingCreatedSubscription : ICarterModule
5{
6    public void AddRoutes(IEndpointRouteBuilder app)
7    {
8        app.MapPost("/dapr/booking-created",
9            [Topic("pubsub", "booking-created")]
10            async (BookingCreatedEvent message,
11                   PaymentProcessingService paymentService) =>
12            {
13                await paymentService.ProcessBookingPaymentAsync(message, CancellationToken.None);
14
15                return Results.Ok();
16            });
17    }
18}

The [Topic("pubsub", "booking-created")] attribute tells Dapr to route messages from the booking-created topic on the pubsub component to this endpoint.

This is a key difference from traditional message consumers. With Azure Service Bus or direct RabbitMQ, you typically use a BackgroundService that polls for messages. With Dapr, messages arrive as HTTP requests, which fit naturally into the ASP .NET Core middleware pipeline.

When working with Dapr, I recommend creating a static class with all the constants in the Shared constants, which you will reuse across your services:

csharp
1public static class DaprConstants
2{
3    public const string PubSubName = "pubsub";
4    public const string StateStoreName = "statestore";
5    public const string SecretStoreName = "secretstore";
6    public const string EmailBindingName = "email-output";
7
8    public static class Topics
9    {
10        public const string BookingCreated = "booking-created";
11        public const string PaymentProcessed = "payment-processed";
12        public const string BookingConfirmed = "booking-confirmed";
13        public const string BookingCancelled = "booking-cancelled";
14    }
15
16    public static class AppIds
17    {
18        public const string HotelsApi = "hotels-api";
19        public const string BookingsApi = "bookings-api";
20        public const string PaymentsApi = "payments-api";
21        public const string NotificationsApi = "notifications-api";
22    }
23}

To call another service through Dapr, use DaprClient.InvokeMethodAsync:

csharp
1// GET request to another service
2var availableRooms = await daprClient.InvokeMethodAsync<List<RoomAvailabilityResponse>>(
3    HttpMethod.Get,
4    "hotels-api",
5    $"hotels/{hotelId}/rooms/available?checkIn={checkIn}&checkOut={checkOut}&guests=1");
6
7// POST request with a body
8var reserveRequest = new ReserveRoomRequest(roomId, bookingId, checkIn, checkOut);
9var reserveResponse = await daprClient.InvokeMethodAsync<ReserveRoomRequest, ReserveRoomResponse>(
10    HttpMethod.Post,
11    "hotels-api",
12    $"hotels/{hotelId}/rooms/reserve",
13    reserveRequest);

The second parameter is the App ID of the target service (as configured in DaprSidecarOptions). The third is the relative path on the target service.

Dapr handles service discovery, routing, and distributed tracing. You do not need to know the target service's address or port.

To use Dapr state management, call the following methods on DaprClient:

csharp
1public class DaprStateManager(
2    DaprClient daprClient,
3    ILogger<DaprStateManager> logger) : IDaprStateManager
4{
5    public async Task<T?> GetStateAsync<T>(string key, CancellationToken cancellationToken = default)
6    {
7        return await daprClient.GetStateAsync<T>("statestore", key, cancellationToken: cancellationToken);
8    }
9
10    public async Task SaveStateAsync<T>(string key, T value, TimeSpan? ttl = null,
11        CancellationToken cancellationToken = default)
12    {
13        if (ttl.HasValue)
14        {
15            var metadata = new Dictionary<string, string>
16            {
17                { "ttlInSeconds", ((int)ttl.Value.TotalSeconds).ToString() }
18            };
19
20            await daprClient.SaveStateAsync("statestore", key, value,
21                metadata: metadata, cancellationToken: cancellationToken);
22        }
23        else
24        {
25            await daprClient.SaveStateAsync("statestore", key, value,
26                cancellationToken: cancellationToken);
27        }
28    }
29
30    public async Task DeleteStateAsync(string key, CancellationToken cancellationToken = default)
31    {
32        await daprClient.DeleteStateAsync("statestore", key, cancellationToken: cancellationToken);
33    }
34}

Use it to implement caching:

csharp
1var cacheKey = $"availability:{hotelId}:{checkIn}:{checkOut}:{guests}";
2
3// Try cache first
4var cached = await stateManager.GetStateAsync<RoomAvailabilityResponse[]>(cacheKey);
5if (cached is { Length: > 0 })
6{
7    return cached;
8}
9
10// Fall back to the database
11var rooms = await roomRepository.GetAvailableRoomsAsync(hotelId, checkIn, checkOut, guests);
12var response = rooms.Select(r => new RoomAvailabilityResponse(...)).ToArray();
13
14// Save to cache with TTL
15await stateManager.SaveStateAsync(cacheKey, response, TimeSpan.FromMinutes(5));
16
17return response;

Dapr is a modern, powerful framework for building distributed applications. It provides a consistent API for all building blocks, and a simple way to configure infrastructure.

When compared to other messaging libraries, which only abstract publishing and consuming events from the message queue. Dapr also provides a consistent API for state management, secrets management, workflows, service discovery, basically all you need to build modern apps.

The main advantage of Dapr is portability. You write your business logic once, and the infrastructure can change independently through component configuration. This makes your microservices truly cloud-native and vendor-agnostic.

To get started with Dapr, I recommend checking out their official documentation.

Hope you find this newsletter useful. See you next time.