# API-002: Actor API design

## Status
Accepted

## Context
Given Dapr is going out with language specific Actor SDKs, we formally introduced an Actor API into Dapr to make Actors are first-class citizen in Dapr. The goal of this review was to ensure Dapr can provide strong support of Service Fabric stateful actors programming model so that we can offer a migration path to the majority of existing actor users.

## Decisions

### Dapr 

* A separate Actor interface is defined.
* Actors should support multiple reminders and timers.
* Actor state access methods are encapsulated in the Actor interface itself.
* Actor interface shall support updating a group of key-value states in a single operation.
* Actor interface shall support deletion of an actor. If the actor is activated when the method is called, the in-flight transaction is allowed to complete, then the actor is deactivated, deleted, with associated state removed. 

### Non-Dapr
* Transaction across multiple API calls is left for future versions, if proven necessary. Due to single-threaded guarantee, such transaction scope might be unnecessary. However, if developer expects an Actor code to behave atomically (in an implied transaction scope), we may have to implement this.

## Consequences

Dapr can provide strong support of Service Fabric stateful actors programming model so that we can offer a migration path to most existing actor users.