Dependency Injection for Microservices: Why I Recommend Dapr

When building microservices, one of the recurring challenges is service-to-service communication. How do we allow services to talk to each other without tightly coupling them? How do we standardise messaging, manage retries, introduce observability, and swap implementations without rewriting the client? In my experience, this is where Dapr excels.

Dapr—short for Distributed Application Runtime—has become one of my go-to tools for simplifying microservice communication. What makes it powerful is that it abstracts away the underlying communication protocol. Whether you're using HTTP, gRPC, or a message bus, Dapr provides a consistent API surface for interacting with services, bindings, and state stores. It’s like dependency injection for microservices.

I started using Dapr heavily in projects like SpaSpace, where we were building a distributed platform using event-driven architecture. Each service needed to publish and consume events, manage state, and integrate with external systems. Rather than reinvent the wheel, Dapr gave us building blocks that just worked—service invocation, pub/sub, secret management, configuration, and more.

One of my favourite features is the pub/sub model. Dapr integrates with various message brokers—like Redis Streams, Azure Service Bus, and Kafka—without requiring your application code to change. You write your event consumers once, and you can swap the broker behind the scenes without breaking your implementation. That kind of portability is invaluable.

Another reason I recommend Dapr is developer experience. Onboarding a new developer to a Dapr-based service is significantly easier because the abstractions are standardised. Instead of explaining the intricacies of RabbitMQ or managing a bespoke client library for Redis, we show them how to talk to the Dapr sidecar.

More recently, Microsoft's Aspire framework has caught my eye. Aspire provides an end-to-end development model with first-class support for Dapr. It’s a welcome evolution from Tye, which we previously used at SpaSpace. While Tye showed promise, it was unstable at times. Aspire, by contrast, feels more polished and supported.

To any developer or architect exploring microservices, I always suggest giving Dapr a serious look. It’s not just a runtime—it’s a philosophy. One that encourages loose coupling, observability, and scalability by default. Whether you're early in your microservice journey or refining an existing system, Dapr can reduce boilerplate, increase agility, and help your team focus on solving real business problems.