Skip to main content
The runtime makes four guarantees. Each is the managed form of a mechanism you’d otherwise build by hand — the C server and mapping table in How it works show where each one comes from. Stated precisely: 1. Exactly one instance per name. idFromName("acct_123") routes every call for that name to one owner — the shard map and router you’d otherwise build by hand, done for you. No two hosts run account acct_123 at once, so the instance is the source of truth for that account. 2. One call at a time — no concurrency inside an instance. This is the per-account pthread_mutex, except you don’t write it and can’t forget it. One thread per instance runs each method to completion before the next starts. await yields the thread, but the next call still won’t start until your method returns. The C debit is correct because it holds the lock across the change; the actor debit is correct because two debits on one account never run at the same time. 3. Writes are durable before the caller sees a result. This is write() + fsync() before you reply. When your method returns, the runtime holds the response until every write you issued has been flushed — the caller can’t observe a result built on an unflushed write. (If a write rejects after the method returns, the call fails with ActorOutputGateError instead of returning success.) 4. Only persisted state survives; memory is a cache. This is “the on-disk snapshot + log is the truth; the in-memory map is a cache.” An instance can be evicted or restarted between any two calls — a deploy, idle eviction, host failure — and instance fields (this.x) vanish while ctx.storage does not. The runtime does the snapshotting and recovery; you just read from storage. Treat memory exactly like a process that can be SIGKILLed at any instant: only what you flushed to storage is real.

Next Steps