The complete feature set — from session-ordered delivery and failure recovery to the operator console, CLI, and extension framework. Grouped by what you're trying to get done.
The messaging model: publish typed events, route them by type, and process them in strict per-key order.
Endpoints publish and consume typed events through Azure Service Bus topics and subscriptions — one topic per endpoint, routed by event type.
Messages sharing a [SessionKey] are handled strictly in order, one at a time. A stuck message blocks only its own session.
Typed request/response conversations over Service Bus sessions, with timeout handling built in.
Schedule events for future delivery and cancel scheduled messages before they fire.
Declare endpoints in code, export the platform config, and provision topics, subscriptions, and routing rules from it — idempotently.
Cosmos DB or SQL Server behind one storage contract — with a conformance suite that keeps every provider honest.
Retries, dead-lettering, session blocking, and operator-driven recovery with recorded outcomes for operators to investigate.
Per-event and per-exception-pattern retry policies with fixed, linear, or exponential backoff strategies.
Unrecoverable exceptions are classified and dead-lettered immediately — no retry budget wasted on a payload that can never succeed.
When a message fails, later messages in the same session are deferred automatically until that session is unblocked at the receiving endpoint.
Once a session is unblocked, its deferred messages are re-published in FIFO order — the backlog drains itself.
Failed events can be resubmitted or skipped from the WebApp while keeping the Resolver's history consistent.
Persist outgoing messages in a SQL Server outbox inside your business transaction; a dispatcher publishes them afterwards. The outbox ties the intent to publish to the database commit; consumers should remain idempotent.
The operational layer that raw Service Bus doesn't give you: a queryable audit of every message, a console to act on it, and automation for the rest.
A central Resolver records every message's outcome — Pending, Completed, Failed, Deferred — as one queryable audit trail.
An authenticated console for inspecting endpoints, events, and messages — with live updates, resubmit/skip actions, alerts, and audit views.
nb command-line toolProvision infrastructure, apply topology, deploy apps, purge queues, and clean up sessions — from a laptop or a pipeline.
Health probes for Service Bus and the message store, plus resolver-lag checks that flag a Resolver falling behind.
Logging, OpenTelemetry metrics, and message validation ship as pipeline behaviors — register the behaviors your application needs.
Failures, dead-letters, and session blocks fan out to pluggable notification channels such as webhooks or email.
You bring events and handlers; NimBus brings the hosting, pipeline, and a full local development story.
Register publishers and subscribers through DI, then configure receiver hosting with AddNimBusReceiver for Workers or Service Bus triggers for Azure Functions.
[SessionKey] sets the ordering scope; validation and description attributes drive schema checks and documentation.
Wrap message handling with your own cross-cutting behaviors — the same delegate-chain pattern the built-ins use.
Passive hooks for received, completed, failed, and dead-lettered events — observe without touching the pipeline.
Run the full pipeline — ordering, retries, outcomes — in unit tests with no Azure connection at all.
The CRM/ERP Aspire sample runs the provisioner, Resolver, WebApp, and adapters with a local Service Bus emulator and SQL Server by default.
A schema registry with REST and MCP surfaces lets AI agents discover event types and participate on the bus as first-class endpoints.
Extensions package up services, middleware, and observers behind one registration. Without any, NimBus runs with its default core behavior.
Extension packages register services, pipeline behaviors, and lifecycle observers through a single AddNimBus() call, composed with a fluent builder.
Configurable notifications on lifecycle events — failure and dead-letter by default — through pluggable INotificationChannel implementations.
ASP.NET Core Identity username/password auth for the WebApp, with email confirmation and reset flows — and optional dual login with Entra ID.