Multi-tenancy patterns in Firebase - Step-by-Step Execution

Process Flow - Multi-tenancy patterns

Start: User Request

↓

Identify Tenant

↓

Shared DB

↓

Serve Data

↓

Response to User

↓

End

The flow starts with a user request, identifies the tenant, selects a multi-tenancy pattern (shared, isolated, or hybrid), serves tenant-specific data, and responds.

Execution Sample

Firebase

// Pseudocode for tenant data fetch
function fetchTenantData(userId) {
  let tenantId = identifyTenant(userId);
  if (pattern == 'shared') {
    return querySharedDB(tenantId);
  } else if (pattern == 'isolated') {
    return queryIsolatedDB(tenantId);
  } else {
    return queryHybridDB(tenantId);
  }
}

This code fetches data for a user based on the tenant and multi-tenancy pattern.

Process Table

Step	Action	Tenant Identified	Pattern Selected	Data Source Queried	Result
1	User sends request	None	None	None	Waiting
2	Identify tenant from userId	tenantA	None	None	Tenant identified
3	Select multi-tenancy pattern	tenantA	shared	None	Pattern chosen
4	Query shared database with tenantA filter	tenantA	shared	Shared DB	TenantA data returned
5	Send response to user	tenantA	shared	Shared DB	Response sent
6	End of request	tenantA	shared	Shared DB	Complete

💡 Request completes after sending tenant-specific data based on chosen pattern.

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
tenantId	None	tenantA	tenantA	tenantA	tenantA
pattern	None	None	shared	shared	shared
dataSource	None	None	None	Shared DB	Shared DB
response	None	None	None	TenantA data	Response sent

Key Moments - 3 Insights

Why do we need to identify the tenant before querying data?

Because the system must know which tenant's data to fetch. Without tenant identification (see Step 2 in execution_table), the system cannot apply the correct filters or select the right database.

What is the difference between shared and isolated patterns in data querying?

In the shared pattern (Step 4), data for all tenants is in one database with tenant filters. In isolated, each tenant has a separate database. This affects how data is queried and secured.

Can the multi-tenancy pattern change during a request?

No, the pattern is selected once per request (Step 3) and remains fixed for that request to ensure consistent data access.

Visual Quiz - 3 Questions

Look at the execution_table, what is the tenantId after Step 2?

A tenantA

B None

C shared

D TenantA data

💡 Hint

Check the 'Tenant Identified' column at Step 2 in execution_table.

At which step is the multi-tenancy pattern selected?

A Step 2

B Step 3

C Step 4

D Step 5

💡 Hint

Look at the 'Pattern Selected' column in execution_table.

If the pattern was 'isolated', which data source would be queried?

A Shared DB

B Hybrid DB

C Isolated DB

D No DB

💡 Hint

Refer to the code in execution_sample and the concept_flow diagram.

Concept Snapshot

Multi-tenancy means serving multiple customers (tenants) from one system.
Patterns:
- Shared DB: One database, tenant data separated by filters.
- Isolated DB: Separate database per tenant.
- Hybrid: Mix of both.
Identify tenant first, then select pattern, then query data accordingly.

Full Transcript

This visual execution shows how a system handles multi-tenancy in Firebase. When a user sends a request, the system first identifies which tenant the user belongs to. Then it chooses a multi-tenancy pattern: shared, isolated, or hybrid. Based on this pattern, it queries the correct data source to get tenant-specific data. Finally, it sends the data back to the user. Variables like tenantId, pattern, and dataSource change step-by-step to reflect this process. Key points include the importance of tenant identification before data access and how different patterns affect data querying.