Should I make one worker for everything or for every API an own worker?

Hi. Workers sit between my client and database. they do auth and database requests.

e.g I have an app with users and posts. The client can make a fetch requests for user profiles (this requires auth), and a fetch request for user posts.

Question: Should I make one worker to handle both fetch requests? Or should I make 2 workers for the two fetch requests? what’s the better practice? Because if I e.g end up using one worker for 30 different fetch requests, I’d have like 2000 lines of code within one worker. wouldn’t that be bad for performance and cause cold starts/delays(since there are no cold starts in workers afaik)

A friend said that a 150kb bundle is fine, but if it gets 2MB big, is that already too much? Where should I draw the line?

Can someone tell me a rule of thumb how I should do things? When should I split up stuff in different workers?

I always thought I should make for every API (post fetch, user account fetch, and so on…) an own Worker.

Disclaimer: One friend told me that I should do everything into one worker so that Cloudflare would cache it more aggressively. That’s true, but I don’t care. I am building a huge app, and I want at scale the best performance. I want the best performance when 10 million people are simultaneously active on my app.

So, what’s the best setup if I have always 10 million active users per second? One worker for everything, or for every API/fetch request one dedicated worker?

My experience only, started with several workers, then I converged into monolithic workers, due to common dependency maintenance. There was never a speed gain, only that worker eviction reduced as it is used more frequently.

If get more than 100,000 req/s then you should split the workers.

1 Like