Do most work sync?

[nathan-jkn]

Hi Folks, we’re starting a new enterprise software platform (like Salesforce, SAP, Workday) and chose Rust. The well-maintained HTTP servers I was able to find (Axum, Actix, etc.) are async, so it seems async is the way to go.

However, the async ecosystem still feels young and there are sharp edges. In my experience, these platforms rarely exceed 1024 threads of concurrent traffic and are often bound by database performance rather than app server limits. In the Java ones I have written before, thread count on Tomcat has never been the bottleneck—GC or CPU-intensive code has been.

I’m considering having the service that the Axum router executes call spawn_blocking early, then serving the rest of the request with sync code, using sync crates like postgres and moka. Later, as the async ecosystem matures, I’d revisit async. I'd plan to use libraries offering both sync and async versions to avoid full rewrites.

Still, I’m torn. The web community leans heavily toward async, but taking on issues like async deadlocks and cancellation safety without a compelling need worries me.

Does anyone else rely on spawn_blocking for most of their logic? Any pitfalls I’m overlooking? Am I just overthinking this?

[emostov]

I would recommend reading the docs on CPU bounds tasks and blocking code.

Spawn blocking can work, but from what I understand it is not recommended for persistent tasks. If you are doing something like long IO, serialization (compute over 100 microseconds) etc, spawn blocking makes sense and should be straightforward to use. Tokio has settings to configure the max number of threads that can be spawned at once. While the default is high, you may want to raise this depending your use.

That being said, you can likely also model your business logic as sync code and run it in normal threads. For example, you might use Axum, but simply have it pass requests over a channel to a standard thread that does sync logic and use a oneshot sender to reply contained in the initial message to reply. One way to do this is you can spin up a constant number of worker threads, and use an mpmc channel to distribute load from async code to the sync code in the worker threads. For other types of CPU bound tasks, rayon can be quite helpful