State and background work
Coordinate with Durable Objects
Recognize when one globally unique stateful object is the right tool for per-user coordination, locks, counters, or real-time rooms.
8 minute lesson
A Durable Object combines an addressable unique instance with strongly consistent storage and serialized access for that object.
Use a deterministic ID when all requests for one user or room must meet the same object. Persist critical state because the object can hibernate or restart. Do not route all global traffic through one object when the workload can be sharded.
The ID defines the coordination boundary. A per-user ID serializes one user’s limiter without making unrelated users wait; a single global ID would create a bottleneck and a larger failure domain. Authenticate before selecting the object and derive the ID from a stable internal identifier, not an attacker-controlled label.
Serialized access does not make in-memory fields durable. Save the decision state in Durable Object storage before returning success, and design alarms or retries to be idempotent. Also remember that calls to external systems can fail after local state changes. Record enough state to resume or compensate instead of holding an implicit lock across unreliable network work.
Design a per-user export limiter that coordinates concurrent export requests without relying on eventually consistent cache data.
Lesson completed