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?

Navigating Nuance: Addressing Cultural Differences in Technical Communication

Many developers learning professional English, particularly those transitioning from different linguistic backgrounds, find subtle but crucial differences in how technical concepts are discussed. It’s not just about knowing the definition of “resiliency,” but understanding the implied expectations and conversational norms around it. For example, a direct, blunt statement like “This service is failing frequently” might be perceived as overly critical or lacking context within some cultures. Similarly, overly verbose explanations in English can sometimes feel inefficient compared to more concise communication styles prevalent elsewhere. Recognizing these nuances allows for smoother collaboration and reduces potential misunderstandings when discussing complex microservices architectures built with Dapr.

One key area where this manifests is around code review feedback. A common phrase you’ll hear – and that some might initially find harsh – is “This could be improved.” While technically correct, it doesn’t offer specific guidance. A more constructive approach, reflecting an understanding of diverse communication styles, would be something like: “I noticed intermittent latency spikes during the test run; perhaps exploring a circuit breaker pattern for this service invocation could enhance its resilience.” This provides context (latency), suggests a solution (circuit breaker) and frames it as an opportunity for improvement rather than a criticism. Similarly, Slack conversations often benefit from softening potentially critical feedback with phrases like “It might be beneficial to…” or “Have you considered…?” These framing devices demonstrate respect for the developer’s perspective and encourage collaborative problem-solving. Focusing on the impact of a change—how it affects performance, security, or user experience—is often more effective than simply pointing out technical flaws.

Furthermore, when writing PR descriptions, avoid overly assertive language. Instead of “Fixed bug,” try “Resolved issue impacting transaction completion rate.” Quantifying the impact – even with estimated percentages – adds clarity and demonstrates an understanding of business priorities. Remember that your goal is to facilitate understanding, not just convey information. The more context you provide, the better the chance of a smooth integration process. This extends beyond simply translating terms; it’s about adopting communication patterns that align with collaborative engineering practices.

dapr export --name my-service --namespace default --output ./my-service/deployment.yaml

This command, using dapr export, exemplifies the kind of detailed instruction often required in technical documentation and discussions. The precision needed to define a deployment configuration – specifying the service name (my-service), namespace (default), and output file path (./my-service/deployment.yaml) – highlights the importance of clarity and accuracy when communicating technical specifications. It’s about conveying not just what needs to be done, but how to do it effectively.