🐝 BusyBee: Fast & Observable Background Job Processing for .NET

Mikolaj Kaminski — Wed, 20 Aug 2025 13:00:00 +0000

Hello .NET folks 👋

We all use tons of amazing open‑source libraries every day. As a way of saying thank you to the community, I decided to build and share my own:

🚀 BusyBee — a lightweight, high‑performance background job processing library for .NET with built‑in OpenTelemetry support.

✨ Why BusyBee?

When building .NET apps, we often need to:

Run fire‑and‑forget jobs in the background
Process queues of tasks efficiently
Monitor and observe code execution in production

BusyBee makes this simple, fast, and observable.

⚡ Key Features

🐝💨 Super fast in‑memory queues built on .NET Channels
⚙️ Configurable: bounded/unbounded queues, overflow strategies, timeouts, parallelism
📊 Built‑in observability: OpenTelemetry metrics + tracing ready out of the box
🔌 ASP.NET Core DI integration
🛑 Cancellation & timeouts support

🚀 Quick Start

Install BusyBee from NuGet:

dotnet add package BusyBee

builder.Services.AddBusyBee();

Enqueue jobs:

await queue.Enqueue(async (services, context, cancellationToken) =>
{
    var logger = services.GetRequiredService<ILogger<Program>>();
    logger.LogInformation("Processing job {JobId}", context.JobId);

    await Task.Delay(1000, cancellationToken);
}, cancellationToken);

🔍 Observability with OpenTelemetry

One of BusyBee’s biggest advantages is first‑class OpenTelemetry support.

You can monitor jobs with traces and metrics in tools like Seq, Prometheus, or Grafana.

Enable OpenTelemetry in your app:

builder.Services.AddOpenTelemetry()
    .WithTracing(tracing => tracing
        .AddSource(BusyBee.Observability.TracingConstants.TraceSourceName)
        .AddConsoleExporter())
    .WithMetrics(metrics => metrics
        .AddMeter(BusyBee.Observability.MetricsConstants.MeterName)
        .AddPrometheusExporter());

📸 Screenshots

Here’s BusyBee in action:

Traces and Logs in Seq

Even though job processing takes place in the background, the continuity of the traces is preserved. The example below shows the entire process from the moment of queuing to the completion of the job.

Metrics in Prometheus

BusyBee has a whole range of built-in metrics. Here's an example metric that shows the number of jobs processed in parallel over time. In this case, the level of parallelism is set to 5.

🐝 Example App

Check out the DemoApp for a complete example with:

Simple Web API + Swagger
OpenTelemetry logging, tracing & metrics
Seq for centralized logging and tracing ingestion
Prometheus integration for metrics scrapping
Docker Compose setup

🙌 Get Involved

📦 NuGet: BusyBee
💻 GitHub: mikasjp/BusyBee

I’d love for you to:

🐛 Try it out in your projects
💡 Share feedback & ideas
🔧 Contribute if you’d like
⭐ And if you find it useful, please leave a star on GitHub — it really helps!

🎯 Final Thoughts

BusyBee is small, but it’s designed to make background job processing in .NET fast, simple, and observable.

If you’ve ever needed a lightweight alternative to heavy job frameworks, give it a try!

Let’s keep the .NET open‑source ecosystem buzzing 🐝⚡

Do we have to await every single C# async method?

Mikolaj Kaminski — Thu, 02 Dec 2021 15:54:07 +0000

Did you ever see code a like that? The method calls another asynchronous method and returns its direct result.

[HttpPost]
public async Task<GetUserQueryResult> Get([FromBody] GetUserQuery query)
{
    var result = await _mediatr.Send(query);
    return result;
}

Okay, it works perfectly well, so what's the matter? Now take a look at the code below:

[HttpPost]
public Task<GetUserQueryResult> Get([FromBody] GetUserQuery id)
{
    return _mediatr.Send(query);
}

I got rid of the async and await keywords. This makes the Get method synchronous. It just passes the task on and does not wait for the result.

Both pieces of code work the same, but are they equally efficient? Let's check it out!

So what's the difference?

The await keyword is syntactic sugar. In fact, when compiled, it is turned into a state machine that manages the asynchronous code. Additional code increases execution time and consumes additional resources.

Let me show you an example class:

public class TestClass
{
    public Task<int> MethodA()
    {
        return Task.FromResult(1);
    }

    public async Task<int> MethodB()
    {
        return await Task.FromResult(1);
    }
}

And its benchmark:

public class Benchmark
{
    private TestClass testObject = new TestClass();

    [Benchmark]
    public async Task NoRedundantOperators()
    {
        await testObject.MethodA();
    }

    [Benchmark(Baseline = true)]
    public async Task RedundantOperators()
    {
        await testObject.MethodB();
    }
}

Here are the results of the benchmark:

Method	Mean	Error	StdDev	Ratio
NoRedundantOperators	34.90 ns	0.738 ns	1.035 ns	0.58
RedundantOperators	60.17 ns	1.243 ns	2.144 ns	1.00

As you can see, the code without unnecessary operators is almost twice as fast!

I have put all the benchmark code in my GitHub repository so you can test it yourself. You can find the repository here.

Finally

I hope I convince you that it is not always worth it to await every single async method call. As always, if you have any interesting thoughts on this topic, please let me know!

DEV Community: Mikolaj Kaminski