DOs are arguably the wrong primitive if you're looking to do transactions across more than one of them. They're essentially partitions, which is how this projec

DOs are arguably the wrong primitive if you're looking to do transactions across more than one of them. They're essentially partitions, which is how this project uses them. If you do transactions across more than one, you are still making blocking, synchronous requests across DO instances which can be across N data centers. You can't really implement locking for blocking writes if you want to implement transactions at a layer above DOs: short of implementing a spin lock (very expensive with workers), you don't have a way to wait for an ongoing transaction to complete. Which is to say, if you had a way to implement transactions with TrueTime in Workers, you could just use the standard KV store and avoid DOs entirely, no? The great part about workers is that you don't pay for idle time—if you're implementing your own locking, you're not able to yield the event loop back to CF. At that point, you've lost most of the benefit of being at the edge (you're making blocking cross-DC requests) and most of the cost benefits of Workers.