Virtual Objects And State

Two concurrent requests both invoke exclusive handlers on virtual object `cart/user-42` to decrement inventory. The integrator assumes they can run in parallel and adds a mutex in application code.

Rely on Restate's per-key single-writer guarantee: exclusive handlers on the same virtual object key are serialized by the runtime, so concurrent invocations on `cart/user-42` queue and run one at a time. Do not add an application-level lock — the object key IS the concurrency boundary. State reads…

A virtual object exposes a `getBalance` handler declared shared so reads can run concurrently with each other, but the integrator writes state inside it.

Shared handlers run concurrently and must NOT mutate object state — they get read access to a consistent view but writing from a shared handler violates the single-writer model and races with the exclusive writer. Keep writes in exclusive handlers only; use shared handlers for reads / queries.

An integrator tries to 'spin up' a virtual object instance before sending it traffic and 'shut it down' when idle, modeling it like a stateful pod.

A virtual object is addressed by key on demand — there is no provisioning / boot step. Invoking a handler on a new key just works; state for an unused key is simply absent. Do not model objects as long-lived processes you start and stop; model them as keyed state + serialized handlers that exist wh…