Why MyServiceBus?
Decide whether MyServiceBus fits your system.
Evaluate MyServiceBus against the system you need to operate: language mix, messaging scope, broker requirements, support model, and tolerance for a pre-1.0 dependency.
Cross-language alignment
You need C#, Java, or Kotlin services to share message intent, envelopes, requests, retries, and failure semantics.
Local mediator dispatch
You want generated commands, queries, notifications, and handlers without adopting a broker.
Preview adoption
You can evaluate and pin a pre-1.0 dependency while APIs, operational evidence, and production gates continue to mature.
Mature .NET platform
Choose MassTransit when its broader feature set, established operations, and commercial support are requirements.
C# and Java are stable reference projections, while experimental Kotlin support provides a coroutine-native sibling over the Java platform runtime. Contracts, consumers, commands, events, requests, retries, and faults retain corresponding meaning. The goal is shared behavior, not identical source code.
MyServiceBus is being developed toward enterprise production confidence, but current releases remain previews. It does not offer MassTransit's commercial support, maturity, long-term product assurances, or complete feature breadth. Evaluate those differences as operational constraints.
License, support, and maturity
MyServiceBus is MIT-licensed. MassTransit v9 and later require a commercial license and pair that model with a mature product, support, and a much broader capability set. Those benefits can be worth paying for when a system needs them.
When a project's needs fit the MyServiceBus common subset—or its current stage does not yet justify that commercial commitment—MyServiceBus provides a smaller, permissively licensed option. The licensing advantage does not remove the cost of adopting a preview or replace an enterprise support relationship.
For local messaging, the same decision applies to MediatR 13 and later, which use a dual commercial/reciprocal license. MyServiceBus keeps its core MIT-licensed and makes generated mediator dispatch a primary product path rather than a supporting feature.
The verified interoperability peer is MassTransit 8.5.1. That technical test pin is separate from the v9+ licensing comparison. Check the official MassTransit licensing documentation ↗ and the MyServiceBus interoperability matrix before deciding.
For an API-by-API adoption view, including readiness and likely pre-1.0 change, see what you can use today and what could change.
Migrate from MassTransit
Introduce one C# or Java participant through the verified wire subset, then move service ownership deliberately.
Follow the MassTransit migration path →Migrate from MediatR
Port commands, queries, notifications, handlers, and pipeline behavior in controlled application slices.
Follow the MediatR migration path →Carry the same vocabulary between ecosystems
MyServiceBus deliberately preserves MassTransit's most useful structural and behavioral ideas. Developers can move between .NET, Java, and Kotlin services without relearning what publish, send, consume, request, retry, or fault means. The APIs remain idiomatic to each language, but the responsibilities, message flow, and failure model stay recognizable. Existing MassTransit knowledge therefore accelerates adoption, but it supports the main cross-platform goal rather than replacing it.
Compatibility is intentional where it supports familiarity and wire-level interoperability. Complete source compatibility and feature parity are not the goal; advanced features may be absent, and each platform keeps its natural dependency-injection, type-system, and asynchronous programming style.
Separate application intent from broker mechanics
Early design questions are usually about communication, not infrastructure. Is the message a command or an event? Who may consume it? Does the sender need an immediate response? What happens after a duplicate, timeout, or partial failure? MyServiceBus lets teams express those decisions through contracts, consumers, endpoints, publish and send intent, requests, retries, and faults before committing the design to native broker concepts.
MyServiceBus gives common messaging behavior a consistent home while still exposing transport configuration where broker capabilities matter.
The in-memory mediator and testing harness provide a fast place to exercise the interaction model. When durability, independent processes, and operational scale are needed, select a broker transport based on the required guarantees and hosting environment. Application messages and consumers retain the same conceptual model while transport configuration supplies the native behavior.
Validate topology, ordering, settlement, throughput, security, and failure behavior against the broker you will operate. The framework postpones an infrastructure choice; it does not erase its consequences.
What direct broker APIs leave to the application
A native client is deliberately close to its broker. That is ideal when you need maximum control, but a production application must then choose and keep conventions for serialization, message identity, type naming, topology, acknowledgement, retries, dead-lettering, request correlation, dependency injection, tracing, and tests. Those choices multiply when .NET and JVM services must interoperate.
Delivery primitives
Channels or clients, native messages, entity declarations, settlement, and every broker-specific feature.
Your responsibility:Build and govern the application-level messaging conventions.
Messaging model
Typed consumers, send and publish intent, portable envelopes, endpoint lifecycle, and shared failure behavior.
Your responsibility:Design contracts, idempotency, service boundaries, and business recovery.
Capability snapshot
One mental model
Send commands, publish events, consume messages, and request responses through aligned C#, Java, and Kotlin concepts.
Portable wire contracts
Use shared envelopes, message type URNs, identifiers, headers, and MassTransit-aware conventions across languages.
Managed failure paths
Configure retry pipelines and use consistent fault, error, and skipped-message destinations.
Low-ceremony setup
Register consumers, choose a transport, configure endpoints, and let the hosted bus manage their lifecycle.
Testable behavior
Exercise consumers and message flows with the in-memory mediator and testing harness before using a broker.
Operational context
Propagate OpenTelemetry context and observe topology, throughput, retries, and failures through optional monitoring.
Typical adoption path
A basic application defines a message contract, implements a typed consumer, registers it with dependency injection, and selects a transport. MyServiceBus then owns endpoint discovery, consumer scopes, topology conventions, serialization, and bus lifecycle for the supported profile.
Choose the Java adoption path that fits the application
Decorator style
For a new Java project, use ServiceCollection.from(...) to structure a MyServiceBus-managed service graph with a composition pattern familiar from the C# client.
Bus factory
Use the bus factory as the default integration boundary and let endpoint or service factories close over the application's existing container.
The Java adoption guide shows concrete Spring, Jakarta CDI, Dagger, and application-owned factory integrations. Kotlin applications can instead select the experimental Kotlin projection, including its Ktor integration pattern.
Use the in-memory mediator for deliberately local flows and fast tests, or run RabbitMQ locally for a realistic broker-backed development loop. The same consumer model can then move into the deployed environment. The getting-started guide walks through the complete first flow in C#, Java, and Kotlin.
How C#, Java, and Kotlin align
The APIs are idiomatic rather than textually identical. A consumer has the same responsibilities and wire behavior in every projection, while each frontend follows its language's dependency-injection and asynchronous programming style. Kotlin shares the JVM runtime with Java but owns its application-facing coroutine contracts.
Project scope and ownership
MyServiceBus starts from MassTransit's messaging vocabulary, envelope conventions, consumer model, and operational semantics. Development then concentrates on stable C# and Java parity, an experimental Kotlin projection, generated registration and dispatch, explicit compatibility and delivery evidence, and a smaller portable core.
It is intentionally not a feature-for-feature reimplementation of MassTransit. “Improve upon” means advancing those owned boundaries, not claiming universal superiority. MassTransit remains the more mature and capable choice for many .NET systems. MyServiceBus commits to keeping its core runtime permissively open source while it evolves through production evidence and community contributions.
What transport portability preserves
The transport is selected at the application boundary. A team can run RabbitMQ locally because it is lightweight and easy to host, then configure Azure Service Bus when deploying the same application to Azure. Contracts, consumers, and the code that sends, publishes, requests, and responds do not need to be rewritten.
RabbitMQ is the verified default profile, and Azure Service Bus is available as a verified preview with documented limitations. Each transport package owns its native connection and topology projection. Broker-specific settings—such as RabbitMQ queue arguments or Azure topology ownership—remain on the relevant configurator instead of leaking into message handlers.
Run transport-level integration tests in each target environment. Switching configuration preserves the application model, but broker topology, delivery guarantees, quotas, security, and operational behavior still differ.
When MassTransit or direct broker APIs are the better choice
- You need a mature, commercially supported .NET service bus: choose MassTransit.
- You need a mature orchestration platform today. MyServiceBus now has cross-language choreography declarations, saga state machines, PostgreSQL saga persistence, and workflow monitoring, but these are evolving preview surfaces without MassTransit's feature breadth or operational history.
- You need a fully integrated, production-promoted outbox today; MyServiceBus has PostgreSQL Bus Outbox capture and hosted dispatch, but Consumer Outbox middleware, cleanup, and crash-matrix promotion remain in progress.
- You need a broker feature or performance control that MyServiceBus does not expose.
- Your organization already has a mature, enforced messaging platform with equivalent conventions.
- The component is a very small bridge or infrastructure tool rather than a business service.
- You accept broker lock-in and want the smallest possible abstraction surface.
- A pre-1.0 library is not appropriate for the system's stability requirements.
Choose MyServiceBus when its common behavior removes repeated application plumbing. Drop to transport configuration—or a native client—when a broker-specific capability is the point of the design.
A practical decision test
If you need to add a Java service to a MassTransit-based .NET estate—or want to evaluate experimental Kotlin support over the same JVM runtime—MyServiceBus may be worth evaluating. Its permissive license can fit an earlier-stage or deliberately smaller system, provided the preview maturity, support, and feature boundaries are acceptable. Choose MassTransit when its mature .NET ecosystem, broader features, and commercial support matter. If the problem is only one native queue with unusual broker requirements, start with the broker API and add abstraction only when the application-level conventions become real.