Hello everybody,
I’d prefer to share tenant-core, a Go toolkit for multi-tenant SaaS purposes.
**The issue it addresses:** in a multi-tenant system, each request must resolve which tenant it belongs to, and each subsystem (cache, fee limits, permissions, metrics) must respect that boundary constantly. Most groups find yourself constructing this incrementally and inconsistently.
**What it supplies:**
– 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 fee limiting, with an optionally available 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 decisions value mentioning:**
– Interfaces stay within the core bundle; concrete implementations (Redis, Prometheus) stay in separate Go submodules, so shoppers solely pull in what they use
– Concurrency-sensitive paths (singleflight beneath cache misses, `sync.Map` competition for the speed limiter) had been benchmarked and profiled moderately than assumed
– The structure doc is express 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 outdated — not claiming API stability but, and I’m already engaged on a breaking change (`Permission` as an outlined sort as an alternative of `string`) based mostly on suggestions from r/golang.
Getting began: tenant-core/GETTING_STARTED.md at essential · sylvinhio676-ux/tenant-core · GitHub
Structure doc: tenant-core/docs/ARCHITECTURE.md at essential · sylvinhio676-ux/tenant-core · GitHub
Suggestions and criticism very welcome.
