Dapr

Dapr is a distributed application runtime. It gives your application local HTTP and gRPC APIs for common distributed-system capabilities.

You keep business logic in your service. Dapr handles selected infrastructure interactions through APIs called building blocks. A building block can invoke another service, publish an event, save state, retrieve a secret, run a workflow, or perform another defined capability.

Dapr is not an application framework, message broker, database, or service mesh. It sits between your application and those systems. You choose which building blocks to use and which backing systems to connect.

The mental model: a local adapter

Each Dapr-enabled application runs beside a Dapr runtime process named daprd. This process is usually called a sidecar.

your application
      |
      | local HTTP or gRPC
      v
 Dapr sidecar
      |
      | building-block API
      v
component or another Dapr-enabled application

Your code calls a stable Dapr API. The sidecar translates that call into an interaction with a configured component or another application.

This boundary separates application logic from infrastructure-specific client code. It also adds another runtime process, configuration surface, network hop, and operational dependency. Dapr is useful when the abstraction earns that cost.

Separate building blocks from components

This distinction is the key to reading Dapr documentation.

• A building block is an HTTP or gRPC API exposed by Dapr.
• A component is an implementation that supplies a capability behind one or more building blocks.

For example, the state-management building block defines operations for key-value state. A state-store component connects those operations to a particular data store. The publish-and-subscribe building block defines messaging behavior. A pub/sub component connects it to a broker.

Components that implement the same interface are intended to be interchangeable. Their metadata, features, and operational behavior can still differ. Replacing one component does not remove the need to test semantics, limits, security, and failure behavior.

See the major building blocks

Dapr groups common application needs into independent APIs.

Building block	Purpose
Service invocation	Call another application by application ID
Publish and subscribe	Exchange messages through a configured broker
State management	Read, write, query, and transact against supported state stores
Bindings	Receive events from or call operations on external systems
Actors	Run stateful virtual actors with managed identity and placement
Workflow	Coordinate durable, long-running application logic
Secrets management	Retrieve secrets through a secret-store component
Configuration	Read configuration values and receive change notifications
Distributed lock	Coordinate mutually exclusive access through a lock store
Cryptography	Perform cryptographic operations without exposing keys to application code
Jobs	Schedule work for later delivery
Conversation	Send prompts to large language models through conversation components

You do not adopt this entire set at once. Each building block is independent. Start with one concrete problem and add only the APIs your application needs.

Follow a service call

Every Dapr-enabled application has an application ID. Service invocation addresses a destination by that ID instead of a fixed host address.

checkout app -> local Dapr sidecar -> remote Dapr sidecar -> inventory app
                     app ID: inventory

The hosting environment provides name resolution. Dapr can apply tracing, access control, mutual TLS between sidecars, and configured resiliency policies along the route.

Your application still owns the endpoint contract and business behavior. Dapr does not decide whether an operation is safe to retry. It does not make a non-idempotent write idempotent.

Follow a component call

Consider a service that saves a shopping cart.

application -> state API -> Dapr sidecar -> state-store component -> database

The application addresses a component by name. The component resource contains its type, version, metadata, and access scopes. Credentials can be referenced through a secret store instead of being placed directly in the component definition.

The common API improves portability at the Dapr boundary. Portability is not automatic beyond that boundary. State stores may support different query, transaction, consistency, concurrency, and metadata features. Check the component specification before choosing or replacing an implementation.

Understand the hosting models

Dapr supports self-hosted and Kubernetes environments.

In self-hosted mode, the Dapr CLI can launch a daprd process beside each application. This works on a developer machine and can also be used on physical or virtual machines. Name resolution uses mDNS by default in the documented self-hosted setup.

On Kubernetes, the sidecar injector can add daprd to an annotated application pod. The control plane includes services for component updates, sidecar injection, certificate issuance, actor placement, and scheduling.

The application-side API remains local in both models. The surrounding installation and operational responsibilities differ.

Place the control plane correctly

The Dapr sidecar handles application API calls. Control-plane services support the runtime on Kubernetes.

Service	Main responsibility
Operator	Watches Dapr resources and delivers component updates
Sidecar injector	Adds Dapr sidecars to enabled pods
Sentry	Issues and rotates workload certificates
Placement	Maintains actor placement tables
Scheduler	Supports Jobs, Workflow, and actor reminders

Not every application uses every control-plane service directly. Placement matters when you use actors. Scheduler supports the APIs that require durable scheduling.

Treat reliability as policy plus application design

Dapr resiliency resources can define timeouts, retries with backoff, and circuit breakers. You can target applications, actors, and components with these policies.

These mechanisms control how Dapr handles selected failed calls. They do not prove that a retry is safe. Before enabling retries, decide how duplicate work is detected and how partial completion is handled.

Health is also bidirectional. A hosting environment can probe the Dapr sidecar. Dapr can probe the application and react when it becomes unhealthy, including stopping subscriptions and short-circuiting service invocation calls.

Build security in layers

Dapr uses the application ID as its application identity and routing unit. In production, Dapr can use mutual TLS between sidecars. On Kubernetes, Sentry acts as the certificate authority for Dapr workload certificates.

Mutual TLS between sidecars does not secure every boundary by itself. The connection between an application and its local sidecar can use API tokens. You can also restrict callable service operations, pub/sub topics, component access, secret access, and enabled sidecar APIs.

Apply least privilege at each layer:

1. Expose only the Dapr APIs the application needs.
2. Scope each component to the applications that may use it.
3. Restrict secrets and pub/sub topics.
4. Define service invocation access policies.
5. Secure the backing system and its credentials.
6. Protect application-to-sidecar traffic where the local boundary is not trusted.

Use observability without confusing it with application insight

Dapr can generate and propagate trace context. It emits sidecar and control-plane logs, metrics, and health signals. It can export traces through OpenTelemetry and Zipkin protocols.

This supplies visibility into Dapr-mediated operations. Your application still needs domain telemetry. A successful state API call does not explain whether the saved state is correct. Combine Dapr telemetry with application logs, metrics, and traces.

Know what Dapr does not replace

Dapr is not a service mesh. A networking service mesh focuses on traffic between services and can cover workloads that do not use Dapr. Dapr focuses on developer-facing application APIs, though the two can overlap in service invocation, security, and tracing.

Dapr also does not replace:

• the database, broker, secret store, or model provider behind a component;
• careful API and event-contract design;
• capacity planning for sidecars and backing systems;
• application-level authorization and data protection;
• tests against the exact component implementation you deploy;
• operational ownership of the Dapr control plane and upgrades.

Decide when Dapr fits

Dapr fits when several services need common distributed-system capabilities and a stable application-facing API reduces repeated integration work. It can also help when teams use different languages or expect infrastructure choices to change.

It fits less well when one small application has a single stable infrastructure dependency, or when the abstraction hides features you must use directly. It may also be a poor trade when the extra process, latency, resource use, and control-plane work exceed the integration cost it removes.

Evaluate one path end to end. Measure latency and resource use. Test component failure modes. Confirm security boundaries. Then expand adoption based on evidence.

A practical learning path

1. Learn the sidecar, building-block, component, and application-ID mental model.
2. Run a quickstart and call one Dapr API over HTTP or gRPC.
3. Compare service invocation with one component-backed API, such as state or pub/sub.
4. Read the exact specification for the component you plan to deploy.
5. Add tracing, metrics, health checks, and explicit resiliency policies.
6. Apply API, service, topic, component, and secret scopes.
7. Test duplicate delivery, timeouts, component outages, sidecar restarts, and upgrades.
8. Study actors, workflow, jobs, and other specialized building blocks only when their models match your problem.