English Vocabulary for Dapr Microservices Developers

Dapr (Distributed Application Runtime) is an open-source project from Microsoft that provides a set of APIs — called building blocks — for building portable, reliable microservices applications. Rather than embedding distributed systems primitives (pub/sub messaging, state management, service discovery) directly into your application code, Dapr moves them into a sidecar process that runs alongside your service. This makes your application code language-agnostic and infrastructure-portable. If your team builds microservices on Kubernetes or any container platform using Dapr, understanding its vocabulary is essential for architecture discussions, configuration reviews, and incident response. This post covers the core Dapr terms.

Key Vocabulary

Sidecar pattern The architectural pattern at the heart of Dapr. A sidecar is a helper container that runs alongside your main application container in the same pod (in Kubernetes) or process group. Your application communicates with Dapr’s building blocks through the sidecar via HTTP or gRPC on localhost, rather than importing distributed systems libraries directly. Example: “Dapr injects a sidecar container into each pod automatically — your service calls localhost:3500/v1.0/invoke/... and the sidecar handles service discovery, retries, and observability without any SDK required.”

Pub/sub component A Dapr building block for event-driven communication between services. Your service publishes a message to a named topic and subscribes to receive messages from a topic — Dapr abstracts the underlying message broker (Kafka, RabbitMQ, Azure Service Bus, Redis Streams) behind a uniform API. Changing the broker requires only a configuration file change, not code changes. Example: “Use Dapr pub/sub to decouple the order service from the inventory service — the order service publishes to the order.placed topic and the inventory service subscribes, with no direct dependency between them.”

State store A Dapr building block for key-value state management. Services save and retrieve state through the Dapr state store API, and the underlying storage (Redis, Cosmos DB, PostgreSQL, DynamoDB) is configured separately as a Dapr component. State is addressable by actor or service across the cluster. Example: “Store the shopping cart state using the Dapr state store API — we can switch from Redis to Cosmos DB in production by changing the component YAML without touching the application code.”

Service invocation A Dapr building block for making synchronous HTTP or gRPC calls from one service to another. Dapr handles service discovery, load balancing, mTLS encryption, and retries automatically. Your service calls the Dapr sidecar with the target service’s app ID, and Dapr routes the request to the correct instance. Example: “Use Dapr service invocation instead of hardcoding the inventory service URL — call localhost:3500/v1.0/invoke/inventory-service/method/check-stock and Dapr resolves the address and retries on transient failures.”

Actor model Dapr’s implementation of the Virtual Actor pattern — a programming model where each actor is a lightweight, stateful object with a unique ID. Actors process one message at a time (no concurrency within an actor), manage their own state via the state store, and can be dormant until needed. Dapr manages actor placement and lifecycle automatically. Example: “Model each user session as a Dapr Actor with the user ID as the actor ID — the actor holds the session state, handles one request at a time to prevent race conditions, and deactivates when the session expires.”

Secrets API A Dapr building block for accessing secrets from secret stores (Kubernetes Secrets, Vault, AWS Secrets Manager) through a uniform API. Your application requests a secret by name from the Dapr sidecar, and Dapr fetches it from the configured secret store without the application knowing which store is in use. Example: “Use the Dapr Secrets API to retrieve the database password — the application calls localhost:3500/v1.0/secrets/my-secret-store/db-password and never needs to know whether the secret is in Vault or Kubernetes Secrets.”

Resiliency policies Dapr’s configurable policies for handling failures in service invocation and pub/sub — including timeouts, retries with backoff, and circuit breakers. You define resiliency policies in YAML configuration files applied to the Dapr sidecar, not in application code, so they can be updated without redeploying services. Example: “Define a resiliency policy with a circuit breaker on the payment service invocation — if the payment service fails 5 times in 30 seconds, the circuit opens and requests fast-fail for 60 seconds to prevent cascading failures.”

How to Use This Vocabulary

Dapr architecture discussions center on which building blocks to use for each integration pattern. A common design decision is “should services communicate via service invocation (synchronous) or pub/sub (asynchronous)?” The answer depends on whether the caller needs an immediate response or can tolerate eventual processing.

Resiliency policy discussions are important in Dapr because the policies live outside the application code. Teams discuss timeouts, retry configurations, and circuit breaker thresholds during service rollout rather than during development — and they can update these policies without a code deployment, which is a significant operational advantage.

Example Conversation

Dmitri: The order service is timing out when it calls the inventory service during traffic spikes. Ola: Do we have a resiliency policy configured for that service invocation? We should add a circuit breaker so inventory failures don’t cascade into order failures. Dmitri: Not yet — I’ll add a Dapr resiliency YAML with a 2-second timeout, 3 retries with exponential backoff, and a circuit breaker threshold. Ola: Also check if the inventory service should use pub/sub instead — if the order service doesn’t need an immediate stock confirmation, async is more resilient.

Practice

1. Explain the sidecar pattern to a developer who is used to importing libraries directly. Focus on why moving distributed systems logic out of your application code and into a sidecar makes your services more portable and easier to maintain. Use the words “language-agnostic,” “infrastructure,” and “configuration.”
2. Design a Dapr architecture for a food delivery app with three services: orders, notifications, and inventory. Identify which service-to-service communications should use service invocation (synchronous) vs. pub/sub (asynchronous) and explain your reasoning for each choice.
3. Explain what a Dapr resiliency policy is and why it is advantageous to configure it in a YAML file outside the application code rather than in the code itself. What operational benefit does this separation provide when you need to adjust a circuit breaker threshold in production?