I'm trying to find the actual value-add here. This feels like TPL but with more steps. Why do we need to serialize the jobs through a Channel ? Couldn't we just do Task.Run and let the runtime take care of scheduling our work?
You have no control over concurrency/scheduling, have to manage scoping, error handling, etc. TPL/Threads add to much low level noise to the logic. Like you could easily blow up the thread pool depending on what you are doing, where a channel based implementation would just deal with spillover and not affect the other threads. You can easily capture scoped services that are disposed by the time the thread executes -…
This is exactly why I built BusyBee. My team found ourselves hand‑rolling something similar almost every time we started a new project. If we kept needing it, I figured there are probably more people in the same situation. So instead of duplicating the same background queue logic across multiple codebases, I decided to build it once, add proper OpenTelemetry support, and keep it simple without extra bloat. That way we can just reuse it and reduce the amount of similar code we have to maintain.