// the find
MassTransit/MassTransit
Distributed Application Framework for .NET
MassTransit is a mature message broker abstraction layer for .NET that sits on top of RabbitMQ, Azure Service Bus, Amazon SQS, Kafka, and a handful of others — including a SQL-backed transport if you don't want to run a broker at all. It handles consumers, sagas (state machines), routing slips (distributed workflows), retries, and request/response patterns. The target is teams building .NET distributed systems who want a consistent programming model regardless of which transport they end up on.
Transport portability is the genuine win here: you can develop and test against the in-memory transport or the SQL transport without standing up RabbitMQ, then deploy against Azure Service Bus without changing your consumer code. The Saga state machine support is solid — modeling long-running processes as explicit state machines with built-in persistence (EF Core, Redis, MongoDB, etc.) prevents a lot of hand-rolled scheduler/flag hell. The test framework (`MassTransit.TestFramework`) is a first-class citizen, not an afterthought, and makes consumer and saga testing straightforward without spinning up infrastructure. The Roslyn analyzers package catches misconfigured consumers and topology mistakes at compile time.
The abstraction leaks constantly once you hit transport-specific features — FIFO queues on SQS, sessions on Azure Service Bus, Kafka partition assignment — and you end up reading two sets of docs simultaneously. The saga state machine DSL has a steep learning curve and error messages when you misconfigure a state transition are genuinely unhelpful. The job consumers feature (for long-running, rate-limited work) is still rough; the documentation is thin and the concurrency semantics surprise people. Finally, the .NET Framework 4.7.2 support creates real drag — the codebase carries compatibility weight that limits modernization, and teams on .NET 8+ will occasionally hit APIs that exist in awkward dual forms because of it.