"Different tenants have different channels — the registry should know the difference."
The Problem Today
The channel registry is a single shared instance. Applications that serve multiple tenants — each with their own connector credentials, sender identities, and channel configurations — must manage per-tenant connector instances themselves, outside the framework.
What We Are Building
A tenant-aware channel registry that resolves connector instances and channel schemas per tenant identifier. The tenant ID is supplied at send time (via message properties or a configurable ambient context). Per-tenant channel configurations are loaded from a configurable source (in-memory, database, configuration provider).
Benefits
- Multi-tenant messaging is supported natively, with no application-level workaround
- Tenant isolation is enforced at the registry level — one tenant's configuration cannot bleed into another's
- Tenant-specific sender identities and credentials are resolved automatically per message
The Problem Today
The channel registry is a single shared instance. Applications that serve multiple tenants — each with their own connector credentials, sender identities, and channel configurations — must manage per-tenant connector instances themselves, outside the framework.
What We Are Building
A tenant-aware channel registry that resolves connector instances and channel schemas per tenant identifier. The tenant ID is supplied at send time (via message properties or a configurable ambient context). Per-tenant channel configurations are loaded from a configurable source (in-memory, database, configuration provider).
Benefits