is there any limit to how many simultaneous outgoing connections can DO? I've sharded my objects into a two layers, with 100 top level DOs and a single section layer object which makes a fetch request to all 100 top level DOs once per second. I'm just wondering how to evaluate what kind of limit on top level shards I could make, before completely splitting off a new separated cluster. 100 seems to be handled fine, but, what if I had 200, 500, or 1000 shard DO's which are all connected to a single root DO? Has anyone tested limits? I've heard that around 1000-2000 req/s seems to be an estimated limit performance wise

Performance completely depends upon your code so it's hard to say how much you can expect.

Of course! 🤦‍♂️

Oh wait, I’d like to have the eyeball request ask it’s locationHint region for an available pool. Can I get that from the request?

That's fair, is there a very rough range that could be expected if the network requests were just a ping?

I have the following DO, will this be able to handle peaks of 5000 requests per minute (with about 3m requests per day)?

I have the following Cloudflare worker attached to it, with caching and fallback to KV when it fails...

I haven't looked at your code enough to be sure, but it seems you intend only to have one instance of this DO running globally. It will probably scale to 5,000 requests per minute, and if you have a high hit rate with your cache layer probably much more than that. That said, DOs are best suited to situations where you instantiate many. You've added a lot of complexity, especially with the KV fallback (which I don't easily recognize the value of). Since the cache is local to one data center, you don't get the single instance transactionality of DO benefit anyway so why not just use KVs across the board with some retry logic to account for the up to 60 second global consistency delay for KV?

The sample has a 300 sec cache. I want to reduce it to 10. Need the updates to be faster. KV 2 might provide that later on. Why the fall back to KV is because I want to have a backup if DO fails because of limits. So your recommendation is sharding right? Like 10 shards orso could handle 50k requests a minute?

Hi, I'm trying to follow the durable objects docs. When it says to create a plain js class. Where am I supposed to create that? next to the default export of the worker?

yes. It can even be blank. export default {}

so, my worker implementation and DO implementation can live in the single

index.ts

?

correct

I see, thanks!

I would recommend starting with one of the templates linked from here https://developers.cloudflare.com/workers/learning/using-durable-objects/#uploading-a-durable-object-worker

Hi, so I tried today to play around with DO, I'm still wrapping my head around it since a lot of things happen behind the scenes. Can I get a reference to a DO and look at its state from a worker? or I have to always call the DO's

fetch

?

You have to call fetch

I see, so I'm building a kind of relay where a server sends data to a worker, and the worker broadcasts that data to any connected clients. I imagine that in this case, I would just pass the worker fetch call to the DO fetch, and implement all logic in the DO? (e.g. Keep track of all connected clients, etc)

Yep

I'm using that design pattern a lot now. I use Pages or a Worker as a simple proxy and do all the heavy lifting in a DO.

Is there any reason? Workers are great because they are stateless, basically infinitely scalable, and run as close to the request as possible, and they have (other than storage) all the features a DO has

Hey, is there a guide on how to share a DO between two different workers?

I have this: Worker 1

ts
await this.storage.put('hello', 'world')
console.log(await this.storage.list())

^^ Outputs the list with

hello

in the storage I start worker 2 Worker 2

ts
console.log(await this.storage.list())

^^ Outputs empty storage

Both workers get the DO using:

ts
let doId = env.MY_DO.idFromName('test')
let doObj = env.MY_DO.get(doId)
return await doObj.fetch(request)

My requests always need data. Often I must make multiple round trips to storage to serve a request. Doing that inside the DO rather than over the wire from the Worker is more efficient. Also, my data is highly localized to a particular tenant and even within that to a particular user, so I can create many low-volume DO instances. As I add more tenants and users, it'll scale out nicely. My original design did more on the Pages/Worker side, but I found the cognitive load of remembering what got done where too heavy. So, I ended up moving all of it except authentication to the DO. I may live to regret my decision, but it feels like the right fit for my use case. Thoughts?

I'm guessing that if I use D1 or R2, I'll do that from the Pages/Worker side. My authentication uses KV and it's on the Pages/Worker side.

have you read https://developers.cloudflare.com/workers/learning/using-durable-objects/#configuring-durable-object-bindings ? what do the [durable objects] binding sections of the wrangler.toml for the two workers look like? Unless MY_DO is bound to the same class_name and script_name, they're two different Durable Object classes, and so trying to get the same idFromName on each of them will resolve to different instances

I did look at the docs there. My two workers have binding like this: worker A:

toml
[durable_objects]
bindings = [{ name = "MY_DO", class_name = "MyDO" }]

worker B:

toml
[durable_objects]
bindings = [{ name = "MY_DO", class_name = "MyDO" }]

Also, not sure if it matters, but the folder structure is like:

worker A
-- src
--- index.ts
-- wrangler.toml
 worker B
-- src
--- index.ts
-- wrangler.toml
MyDo.ts

with each worker exporting the DO class like:

ts
export { MyDO } from '../../MyDo.ts'

Could it be related to the fact that I'm exporting the class from each worker, so each worker gets a new instance?

workerA/src/index.ts MyDO is a different class from workerB/src/index.ts MyDO, if you ask for an instance of each of them, they are unrelated