Patterns to scale actix-web and diesel



I’m currently evaluating rust for a HTTP API and made several PoCs.

One thing I’m not confident with yet is: How to scale actix-web and diesel:

I have my DbExecutor and messages like FindUsers and CreateUser

But how to scale the code with 200+ messages ? I cannot simply put the 200+ messages in a single source file.

Should I create multiple DBActor (1 actor per type of my mode) ?
Should I split my DbExecutor messages in multiple files (1 file per type of my model) ?

Or is there other patterns I’m not yet aware to scale the actor model applied to HTTP service ?

Best regards,


The best way would be to throw traffic at your prototype and see where are the bottlenecks.

Actix-web creates one copy of your state per CPU core. So stuff you put there usually scales reasonably well - you’re not bottlenecked by any single object, and you’re also not hitting memory limits from having one object per request.

If your DB does the heavy lifting then scaling would be reduced to the typical problem of DB scaling.

If the front-end is CPU-bottlenecked then Actix-web should handle that reasonably well.

If you have lots of long-lived connections waiting due to external APIs/network latencies/etc. you may need to look into increasing number of concurrent connections Actix-web wants to handle.

1 Like

Hi, Thanks for the response!

I apologize if I wasn’t clear enough, I will update my post, but I’m talking more about scaling the code instead of scaling in term of performance.


Ah, if the boilerplate is the problem, macros are usually the solution. If 200 invocations of a macro is still too much, you have an option of using to generate Rust code for you (e.g. based on some external schema).

1 Like