Dapr Provides a Sidecar Runtime for Microservices. The Services Still Need External Orchestration.

Vendor and Product Reality

Dapr originated at Microsoft, was donated to the CNCF, and has reached graduated status. Its architecture attaches a sidecar process to each application instance and exposes a uniform HTTP/gRPC API for cross-cutting concerns: pub/sub messaging across pluggable brokers, state management across pluggable stores, service invocation with mTLS and retries, input/output bindings to external systems, virtual actors with single-threaded turn-based execution, secrets retrieval, and a workflow engine for durable orchestrations. Components are configured through Kubernetes CRDs (or YAML in self-hosted mode); the sidecar reads the configuration and exposes the configured backends behind the uniform API.

The value proposition is real. Application code calls a single API for state regardless of whether the underlying store is Redis, Cosmos DB, or Postgres. Pub/sub topics decouple producers from brokers. The actor model gives developers a familiar single-instance-per-id execution semantic without forcing them to manage placement or persistence. The sidecar pattern keeps language-specific SDKs thin and portability genuine. For teams building polyglot microservices on Kubernetes, Dapr removes a category of plumbing.

The architectural question this article addresses is not whether the sidecar pattern works. It does. The question is where the rules that govern a given piece of state live, and what travels with the state when it moves between sidecars, between clusters, or between organizations.

Architectural Gap: Rules and Policy Are Server-Side

In Dapr, a piece of state is a value associated with a key under a configured store. The rules that govern that value — which services may read it, which may write it, what consistency model applies, what TTL applies, what retry policy applies, which subscribers receive notifications when it changes — are encoded in the component CRD, in resiliency policies, in access-control policies, and in the sidecar's configuration. The sidecar consults its configuration and applies those rules. The state does not carry the rules. The runtime carries them.

The same pattern holds for pub/sub: subscriptions, topic-level access control, and retry behavior are configured at the sidecar; the messages do not carry their own subscription policy. It holds for actors: placement, reminders, and concurrency are runtime concerns. It holds for workflow: the durable orchestration logic is code deployed to the runtime, and the data the workflow manipulates flows through the orchestrator without carrying its own evaluation.

For application development this is a sensible split. For governance it produces the same gap that broker-side workflow engines produce: the audit and authority story is a property of the runtime's configuration, not a property of the state. When state moves between Dapr instances — across clusters, across tenants, across organizations — it does not carry the policy under which it was written. Whatever sidecar receives it next applies whatever rules its own configuration encodes. Continuity of governance depends on operational discipline at every receiving runtime.

A second consequence is that Dapr services are request-driven. The state sits in its store. The actor sits idle until a message activates it. The workflow advances when an event arrives. None of these execution models include a self-evaluation cycle in which the state itself decides whether conditions warrant action. The execution model is "wait to be told." For microservice request/response work this is correct. For state that should evaluate itself — that should detect that a condition has been met and act on it — there is no native primitive in Dapr that performs that evaluation as a property of the state object rather than as a property of code running elsewhere.

What Memory-Resident Execution Provides

The memory-resident-execution primitive treats the state object as a self-executing entity. The object carries its own data, its own credentialed policy, and its own evaluation cycle. On each cycle it inspects its data, evaluates its policy, and decides whether to act. The runtime hosts the object — provides scheduling, persistence, messaging — but does not own the rules that determine what the object does. The rules ship with the state.

Two consequences follow. First, governance is portable. When the object moves — to a different sidecar, a different cluster, a different organization — the policy moves with it. The receiving runtime cannot widen the object's authority by virtue of having a more permissive configuration; the object admits its own actions against its own credentialed policy regardless of host. Lineage of state transitions is recorded against the same policy, producing an audit trail that is intrinsic rather than configuration-dependent.

Second, execution is intrinsic rather than triggered. The object self-evaluates. It does not require an external event to decide to act. A condition embedded in its policy fires when its data satisfies the condition; the resulting action is itself admitted against the policy and recorded against the lineage. Request-driven invocations remain available — the object can still respond to messages and HTTP requests — but they are not the only path by which the object acts.

Composition Pathway With Dapr

The composition with Dapr is layered. Dapr's state stores remain the persistence substrate; memory-resident objects use Dapr's state API to persist themselves between cycles. Dapr's pub/sub remains the messaging substrate; objects emit policy-admitted events through the configured broker. Dapr's actor model provides a natural placement substrate for memory-resident objects, with the addition that the actor's behavior is not a code class deployed to the runtime but a policy structure carried by the object itself. The actor framework hosts the object; the object decides what to do.

The execution cycle is supplied by an evaluator that runs alongside the Dapr sidecar — either as an additional sidecar or as a Dapr extension — and that periodically (or event-triggered) wakes each hosted object, hands it its state and its policy, and admits any actions the object proposes. Admitted actions flow back through Dapr's API surface: state writes through the state API, messages through pub/sub, external calls through bindings and service invocation. The infrastructure value Dapr provides is preserved. The authority over what each object does becomes a property of the object.

Dapr's workflow building block becomes a special case. Where today the orchestration logic is deployed code, in the composed architecture the orchestration is a memory-resident object whose policy encodes the workflow. The workflow's authority travels with the workflow; the runtime executes it without owning it.

Commercial and Licensing Posture

Dapr is open source under CNCF stewardship; commercial momentum sits with vendors who package, distribute, and support Dapr distributions — Diagrid being the most prominent — and with platform teams at large enterprises that have standardized on Dapr for polyglot microservice fabrics. The commercial story is portability and developer productivity. The exposure is the same exposure visible across the runtime category: as governance obligations migrate from "what the system did" to "under what authority each unit of state acted," configuration-side authority becomes structurally insufficient, and the runtimes that ship rules with state will be the runtimes that meet the obligation natively.

Adopting the memory-resident-execution primitive as the layer above Dapr's building blocks converts the exposure into a position. Dapr's portability story is preserved and extended: not only does the application code travel across stores and brokers, the governance of each piece of state travels with it. Licensing terms contemplate distribution-level and platform-level structures appropriate to the CNCF ecosystem and to the commercial Dapr distributors. The patent is positioned at the layer where authority lives — inside the state object — and the composition pathway preserves the investment that platform teams have already made in Dapr as the runtime substrate for distributed applications. Existing CRDs, existing component manifests, existing pub/sub topologies, and existing actor placements continue to function; the addition is that the state hosted on top of those substrates carries its own governing rules and its own evaluation cycle, so that the question "under what authority did this state change" has a structural answer rather than a configuration-dependent one.