If you come from EC2, Lambda, or Worker-plus-database architecture, Durable Objects feel unusual because they shift the boundary between business logic and state. A counter stops being just a row and becomes a named stateful owner.
/counter/abc/incr -> increments counter abc /counter/abc/get -> returns current value If compute restarts, the counter should not reset.
That requirement immediately tells you memory alone is not enough. The durable value must live somewhere persistent.
Client -> ALB / API Gateway -> EC2 app or Lambda -> Database
Business logic lives in compute. Durable state lives in the database. The counter is a row or item, and the app code interprets it.
counter identity = DB key counter state = DB row or item counter logic = app code
Client -> Worker -> D1 table
The Worker receives the request, parses the counter ID, runs SQL, and returns the value. The object exists only as a concept inside stateless code.
Worker = stateless business logic D1 = relational durable state
Client
-> Worker
-> counter:abc Durable Object
|- in-memory state
|- private durable storage
Now the counter is not just data. It is an addressable stateful object with identity, behavior, memory while active, and private storage.
The Worker should not own the increment itself. It becomes the outer API layer that routes to the right named object.
/counter/abc/incr -> send request to counter:abc DO
The DO becomes the owner of mutation and lifecycle rules.
load count increment persist return new value
That is the real mental shift: some business logic intentionally moves closer to the state it owns.
In the D1 model, the counter is a row and the Worker owns the logic. In the DO model, the counter becomes a named stateful owner and the Worker mainly routes requests to it.