I was thinking to sidestep it by having the DO open a WS to another DO

afaik there is only the total storage limit (10GB, account wide), and limit per key (32KiB)

You could elevate the "balances" class to not sit under a user, but be 'global'. Then you could address it directly.

That would at least half the number of requests incurred.

Yea thats what I'm thinking but it's a hack around billing

Kinda hacking the software cuz it doesnt fit into a billing model is bleh

10GB, which can be extended of course?

Not really. Totally valid. Think about how banks would function. Many people can have many accounts. So "account" needs to be a global thing and not just a child of "user".

10GB is (hard?) limit during the open beta, once GA you will pay for what you use

Doing operations like addng/subbing balance needs to be syncrobized

If the balance sits in a global DO

Perfect!

Once there are 100,000 users that dO will slow to a crawl

Each user needs there own DO to scale properly

Nah, not a single instace. One instance per balance!

What do you mean by be global then?

So if I'm understanding this correctly, I'd structure your data like this: - "User" DO class - "Account" DO class Each user has their own instance of the

User

class, and each account has its own instance of the

Account

class, where a

User

can have zero, one, (or multiple)

Accounts

. If you know the

Account

ID with the incoming request, you can just go directly to the account's instance, rather than going through the user instance. If you want to find out which accounts a

User

has, you can go to the user's instance and list the account IDs from there.

But if User = Account in that it's always a 1-1 relationship, then sure, you could flatten it all into a single DO class.

(I enjoy thinking about data layout like this way too much lol)

Sorry, "global" was maybe a confusing term. I just meant that Account isn't a descendant of User. Unlike what @User might be planning (depending on how who's authorized to see what albums/posts).

I see what you mean, so a users account can be found without hitting the user DO

Precisely.

I think unsyncronized readonly storage for a DO that can be read without fetching into the DO would solve my problems. Then I can check the balance without fetching into the DO. As well as update/changed events on a DO or KV worker storage

Would fix my problems

that’s KV for ya...

bonus: it’s even faster

Yeah, absolutely. You could cache the data in KV if you're okay with the balance possibly being wrong. But that's just the CAP theorem. Can't have both.

I mean, I absolutely envision using DO tightly w KV for these reasons... but namely best read/user performance when writes (or synchronized reads) aren’t necessary

Read from DO memory is cheaper than KV read, isnt? 🤔 You dont need to access storage for each read, especially when you are accessing same DO multiple times per minute

128MB limit on that memory gotta be careful if its userinput