Designing Event-Driven Serverless Architectures with .NET 8, Azure Functions, and Dapr

Why event-driven serverless matters today

Enterprises are processing over 4.1 billion events per day, according to a recent cloud usage report. Traditional monoliths cannot keep up with that velocity without costly over-provisioning. An event-driven, serverless model lets you scale compute only when a message arrives, reducing OPEX by up to 30% for many workloads.

Combining .NET 8, Azure Functions, and Dapr

.NET 8 brings native AOT compilation, reduced cold‑start latency, and a unified minimal API model. Azure Functions provides a fully managed serverless platform that integrates with the Azure ecosystem out of the box. Dapr adds portable building blocks such as pub/sub, state stores, and bindings, letting you write code once and run it on any cloud. Together they form a low‑friction stack for building resilient, event-driven services.

Preparing the development workstation

Start with Windows 11 or a recent Linux distro. Install the .NET 8 SDK (version 8.0.100 or later) and the Azure Functions Core Tools v4. Use the Dapr CLI (v1.12) to run a local sidecar. A quick checklist:

• dotnet --version → 8.0.100
• func --version → 4.0.4744
• dapr --version → 1.12.0

Run

dotnet new console -n SampleApp && cd SampleApp

func init --worker-runtime dotnetIsolated

Building a basic Azure Function that subscribes to Dapr pub/sub

The following C# snippet shows a function that listens to the "orders" topic on the "pubsub" component. The Dapr attribute handles the subscription registration automatically.

using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Http;
using Dapr;
using CloudEvents;

public class OrderProcessor
{
    [Function("OrderProcessor")]
    public async Task Run(
        [DaprSubscribe("pubsub", "orders")] CloudEvent orderEvent,
        FunctionContext context)
    {
        var logger = context.GetLogger("OrderProcessor");
        logger.LogInformation($"Received order {orderEvent.Id}");
        // Insert business logic, e.g., call a downstream service or update a state store
    }
}

Note the use of CloudEvent which Dapr emits by default, preserving schema and metadata.

Running locally with Dapr sidecar

Start the sidecar with a simple pubsub component (Redis is a common choice). Create a file components/pubsub.yaml:

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

Then launch both the function host and Dapr:

dapr run --app-id order-service --app-port 7071 --components-path ./components func start

Publish a test event with the Dapr CLI:

dapr publish --pubsub pubsub --topic orders --data '{"orderId":12345,"amount":250.75}'

Deploying to Azure

Azure Functions supports Dapr integration via the "Dapr" extension. Add the extension to your project:

dotnet add package Microsoft.Azure.WebJobs.Extensions.Dapr

In host.json, enable the Dapr extension and point to the Azure Redis Cache you provisioned:

{
  "extensions": {
    "dapr": {
      "componentsPath": "./components"
    }
  }
}

Deploy with the Azure CLI:

az functionapp create \
  --resource-group MyRG \
  --consumption-plan-location westus2 \
  --runtime dotnet-isolated \
  --functions-version 4 \
  --name order-service-func \
  --storage-account mystorageacct

func azure functionapp publish order-service-func

After publishing, the Dapr sidecar runs inside the Functions sandbox, automatically registering the subscription with the Azure Redis pub/sub instance.

Observability, scaling, and cost considerations

Azure Monitor captures Function execution metrics; combine them with Dapr metrics exposed on /v1.0/metrics to get a full picture of latency per event. Configure the Function app to use the Premium plan with a minimum of 1 instance to keep cold starts under 100 ms, while still benefiting from auto‑scale based on event volume. In a recent benchmark, a .NET 8 isolated Function processed 12,000 messages per second with a 95th‑percentile latency of 85 ms when paired with Dapr pub/sub.

Key takeaways

By leveraging .NET 8’s performance, Azure Functions’ managed runtime, and Dapr’s portable building blocks, developers can construct truly event‑driven serverless solutions that are cloud‑agnostic, observable, and cost‑effective. Start with a local Dapr sidecar, validate the flow, then push to Azure with minimal configuration changes.

Author: Mahmut Sarıkaya — sarikayadev.com

Sources

• Microsoft Docs – Azure Functions .NET isolated worker
• Dapr Documentation – Pub/Sub building block
• .NET Blog – Performance improvements in .NET 8