Hello everybody,
I’d prefer to share tenant-core, a Go toolkit for multi-tenant SaaS functions.
**The issue it addresses:** in a multi-tenant system, each request must resolve which tenant it belongs to, and each subsystem (cache, charge limits, permissions, metrics) must respect that boundary persistently. Most groups find yourself constructing this incrementally and inconsistently.
**What it offers:**
– Tenant decision (subdomain-based resolver included), propagated by way of `context.Context`
– A `Retailer`/`CachedStore` abstraction with a singleflight-based cache to keep away from stampedes
– Actual-time ban propagation throughout situations by way of an `EventBus` (in-memory or Redis)
– Per-tenant RBAC (roles are scoped per tenant, not international)
– Per-tenant charge limiting, with an non-obligatory Redis-backed distributed variant
– A framework-agnostic Admin API with pluggable authentication
– Adapters for `internet/http`, Gin, Echo, and Chi — the core has zero framework dependency
**Design selections value mentioning:**
– Interfaces stay within the core package deal; concrete implementations (Redis, Prometheus) stay in separate Go submodules, so shoppers solely pull in what they use
– Concurrency-sensitive paths (singleflight below cache misses, `sync.Map` rivalry for the speed limiter) had been benchmarked and profiled somewhat than assumed
– The structure doc is specific about present limitations (e.g. the occasion retry queue is best-effort in-memory, not a sturdy Outbox)
It’s `v0.2.0`, a few month previous — not claiming API stability but, and I’m already engaged on a breaking change (`Permission` as an outlined kind as a substitute of `string`) primarily based on suggestions from r/golang.
Getting began: tenant-core/GETTING_STARTED.md at important · sylvinhio676-ux/tenant-core · GitHub
Structure doc: tenant-core/docs/ARCHITECTURE.md at important · sylvinhio676-ux/tenant-core · GitHub
Suggestions and criticism very welcome.
