diff --git a/v2/multitenancy/architecture.mdx b/v2/multitenancy/architecture.mdx index 5b67e9764..9e3a7d7e3 100644 --- a/v2/multitenancy/architecture.mdx +++ b/v2/multitenancy/architecture.mdx @@ -44,7 +44,7 @@ For multiple tenants, you can run the same backend and frontend across all tenan - In the above diagram, we see setup for: - **Single tenant, single app (top left)**: This is a simple use case that doesn't require the multi tenant feature. - - **Multi temant single app (top right)**: This is case wherein you have different customers using the same application, but each customer has their own set of users and login methods (each customer is a unique tenant in SuperTokens). + - **Multi tenant single app (top right)**: This is case wherein you have different customers using the same application, but each customer has their own set of users and login methods (each customer is a unique tenant in SuperTokens). - **Single tenant, multi app (bottom left)**: This is a case wherein you have multiple applications running on the same SuperTokens core instance, but each application has just a single user pool. This could be two different apps in your organisation, or two different dev environments for the same app (or some combination of this). - **Multi tenant, multi app (bottom right)**: This is a case wherein you have multiple applications running on the same SuperTokens core instance, and each application has its own set of tenants. This could be two different apps in your organisation, or two different dev environments for the same app (or some combination of this). -- The database layer in the above is shown as a single block for each of the scenarios, but for multi tenant, multi app, you can have multiple databases, one for each app, and / or one for each tenant. \ No newline at end of file +- The database layer in the above is shown as a single block for each of the scenarios, but for multi tenant, multi app, you can have multiple databases, one for each app, and / or one for each tenant.