How the mental model changes when a counter stops being just a database row and becomes a named stateful owner.
Durable Objects: Business Logic Close to State
A three-part series for readers who understand stateless compute and databases, but want a cleaner mental model for why Durable Objects feel different. The sequence starts with the architectural shift, then explains the runtime model, then covers where business logic should actually live.
How Durable Object classes, object IDs, live instances, and storage relate to each other.
When to use D1, when to use a DO, and why some business logic intentionally moves closer to state.
Read The Series
The Through-Line
Durable Objects look simple at first: a stateful object on Cloudflare. The real shift is architectural. Some logic that usually lives in stateless compute moves closer to the stateful owner that protects it.
Worker = router / outer API layer DO = stateful owner, coordinator, lifecycle boundary
Why Split It
The original draft was blending three different questions: what the mental shift is, how Durable Objects actually exist and persist, and what kinds of business logic should move into them.
Reading Order
row and stateless app -> object identity and live instance -> state ownership and business logic
That order keeps the runtime details grounded in a concrete architectural problem.
Memory Line
Durable Objects are not just storage and not just compute. They are Cloudflare's primitive for named stateful ownership with logic attached.
3-part series