Sharding explained

AuthP's multi-tenant uses the enum TenantTypes to define what type of multi-tenant you want to use. By default all the tenant's data is stored in one database, with a DataKey to select each tenant's data. See Multi-tenant explained documentation for an overview of the multi-tenant options.

But if you add the SetupMultiTenantSharding extension method to your registering of the AuthP code, then an extra TenantTypes called AddSharding is added, which adds the extra ability for a tenant to store its data in its own database. This means that you have two approaches to build your multi-tenant app: either Hybrid or Sharding-only (see diagram below to explain these two approaches).

Choosing between the Hybrid or Sharding-Only approach

The Hybrid and Sharding-Only approaches have pros and cons which I show in the table below

What	Hybrid	Sharding-Only
Summary	Good if you have a large range of small and large tenant data. Use shared db for small tenants and Sharding-Only for large tenants	Best performance and easy to use, but costly if you have lots of cloud databases (consider Azure SQL Database elastic pools )
Feature diffs	"Sign up now" is limited 👎	Extra Sharding-Only services makes coding easier 👍
Easy of coding	Supporting both tenant types takes a bit more work	Simpler because only need to handle tenant type
Easy for admin	It takes two steps to add a new Tenant	It takes one step to add a new Tenant (and obvious)
Easy for tenant user	Good	Good
Performance	Tenants sharing one database is slower	Best performance
Backups	Tenants sharing one database is difficult	Good: each database can be backed up

Additional resources

• ???????????????????

This means that when the AddSharding enum is added, then for each HTTP request from a tenant user (i.e. a user that is linked to a specific tenant) the multi-tenant code must select a database so that they can access the tenant's data. The AuthP does this via two parts

1. Getting the database server from the connection strings

Anyone that uses ASP.NET Core will know that the appsettings.json file contains a ConnectionStrings section that holds connection strings. These connection strings usually everything you about a database (database name, server name, authentication, etc.) you want to use. But for AuthP sharding code uses the connection strings to access the server name, authentication, etc. but it will add the database name.

If you look at Example6's appsettings.json you will see that the first connection string (called "DefaultConnection") has the normal format, i.e with the database name included, but the other connection string don't have a database part, which means only defines the server.

So, how do we get the database name? See below.

2. Getting the database name from the sharding entries.

AuthP holds a list of the entries (known as sharding entries) that provides the data needed to create a complete connection string. Each sharding entry contains

Name	What is contains
DatabaseName	The name of the database
ConnectionName	The name of the connection string defining the server
DatabaseType	The EF Core's short name (e.g. SqlServer) of the database type to use
Name	This is the unique key to this entry

See ???? document to see the actual steps provide the created connection string is built and then used to allow a tenant user can access the tenant's data.

In AuthP version 6 and above allows you select whether you want to use Hybrid or Sharding-Only approach. Here are the changes between the Hybrid or Sharding-Only approach.

Hybrid selected

• The "DefaultConnection" connection string, which provides the database use by AuthP's to hold its data, is shown in the list of connection strings available to add sharing tenants.
• On the first deployment of your multi-tenant application to a new web server, then a default sharding entry is added to the sharding entries and linked to the "DefaultConnection" connection string. This default sharding entry allows you immediately add sharing tenants to the database defined by the "DefaultConnection" connection string.

This means you can create as sharing tenant without needing to add a new sharding entry.

Sharding-Only selected

• The "DefaultConnection" connection string is not listed in the connection strings available to add sharing tenants, unless the "DefaultConnection" connection string is the only connection string. NOTE: having single "DefaultConnection" connection string makes the app work without adding another connection string - you can create new tenant databases using the server defined in the "DefaultConnection" connection string.
• On the first deployment of your multi-tenant application to a new web server the list of sharding entries is empty.

This means you can create sharding-Only tenants (via the new IShardingOnlyTenantAddRemove ??? service) immediately - see ???

How to select Hybrid or Sharding-Only approach

The SetupMultiTenantSharding extension method ?????????????????? ????????????????????????????? ??????????????????????????????