All Roadmaps›☁️ Salesforce Developer›Phase 2›Multi-Tenant Architecture & Metadata-Driven Platform

Multi-Tenant Architecture & Metadata-Driven Platform

0/4 in this phase0/41 across the roadmap

📖 Concept

Salesforce runs on a multi-tenant architecture — thousands of organizations (tenants) share the same physical infrastructure, application code, and database instance. Understanding this is fundamental to every design decision you make.

How multi-tenancy works:

  1. Shared infrastructure — All customers run on the same servers, same database clusters, same application code
  2. Logical data separation — Each org's data is isolated via an OrgId partition. You can never accidentally access another org's data
  3. Metadata-driven customization — Your "custom objects," "custom fields," and "page layouts" are all stored as metadata rows in shared tables, not as new database columns
  4. Governor limits — Because resources are shared, Salesforce enforces strict limits per transaction to prevent any one tenant from monopolizing resources

The metadata-driven model: Instead of creating a new database table when you create a custom object, Salesforce stores your object definition as metadata. The actual data is stored in shared tables with generic columns (like Value0, Value1, etc). When you query your custom object, the platform dynamically maps your field names to the underlying generic columns.

Traditional app:  CREATE TABLE Invoices (id INT, amount DECIMAL, ...)
Salesforce:       INSERT INTO CustomEntityDefinition (OrgId, ObjectName, ...) 
                  VALUES ('00D...', 'Invoice__c', ...)

Why this matters for developers:

  • Performance — Your SOQL queries are translated to highly optimized SQL with OrgId filters. Poorly designed queries affect everyone on the instance.
  • Governor limits — You get 100 SOQL queries, 150 DML statements, etc. per transaction because you're sharing resources.
  • No raw SQL — You can't write SQL. SOQL is a constrained query language that prevents expensive operations (no arbitrary JOINs, no full table scans without selective filters).
  • Automatic upgrades — Salesforce pushes 3 releases per year (Spring, Summer, Winter). Your customizations must survive these upgrades.

Instance architecture:

  • Pod — A pod is a cluster of servers hosting multiple orgs. Example: NA44, EU18, AP15
  • Instance — Your org runs on a specific instance (e.g., na44.salesforce.com)
  • Trust site — status.salesforce.com shows real-time health of all instances

🏢 Enterprise impact: When a shared instance has performance issues, ALL orgs on that instance are affected. This is why Salesforce is extremely protective of query performance and enforces governor limits so strictly.

💻 Code Example

codeTap to expand ⛶
1// Understanding multi-tenancy through governor limits
2// Every line of Apex runs within strict resource constraints
3

4public class GovernorLimitDemo {
5    
6    // Check current governor limit consumption
7    public static void showLimits() {
8        System.debug('SOQL Queries: ' + Limits.getQueries() + 
9            ' / ' + Limits.getLimitQueries());
10        System.debug('DML Statements: ' + Limits.getDmlStatements() + 
11            ' / ' + Limits.getLimitDmlStatements());
12        System.debug('DML Rows: ' + Limits.getDmlRows() + 
13            ' / ' + Limits.getLimitDmlRows());
14        System.debug('CPU Time: ' + Limits.getCpuTime() + 
15            'ms / ' + Limits.getLimitCpuTime() + 'ms');
16        System.debug('Heap Size: ' + Limits.getHeapSize() + 
17            ' / ' + Limits.getLimitHeapSize());
18        System.debug('Callouts: ' + Limits.getCallouts() + 
19            ' / ' + Limits.getLimitCallouts());
20    }
21    
22    // This code demonstrates WHY governor limits exist
23    // BAD: This would crush a shared database
24    public static void antiPattern() {
25        // This trigger processes 200 records (bulk insert)
26        // Without governor limits, this would execute:
27        //   200 SOQL queries × 200 DML operations = 40,000 database ops
28        //   On a shared instance with 10,000 orgs = potential meltdown
29        
30        // for (Account a : Trigger.new) {
31        //     List<Contact> contacts = [SELECT Id FROM Contact 
32        //         WHERE AccountId = :a.Id]; // SOQL in loop!
33        //     for (Contact c : contacts) {
34        //         c.MailingCity = a.BillingCity;
35        //         update c; // DML in loop!
36        //     }
37        // }
38    }
39    
40    // GOOD: Respects multi-tenant architecture
41    public static void bulkifiedPattern(List<Account> accounts) {
42        // Collect all account IDs (in-memory operation — no limits)
43        Set<Id> accountIds = new Set<Id>();
44        for (Account a : accounts) {
45            accountIds.add(a.Id);
46        }
47        
48        // ONE query for all contacts across all accounts
49        List<Contact> allContacts = [
50            SELECT Id, AccountId, MailingCity 
51            FROM Contact 
52            WHERE AccountId IN :accountIds
53        ];
54        
55        // Build a map for efficient lookup
56        Map<Id, List<Contact>> contactsByAccount = new Map<Id, List<Contact>>();
57        for (Contact c : allContacts) {
58            if (!contactsByAccount.containsKey(c.AccountId)) {
59                contactsByAccount.put(c.AccountId, new List<Contact>());
60            }
61            contactsByAccount.get(c.AccountId).add(c);
62        }
63        
64        // Apply changes in memory
65        List<Contact> contactsToUpdate = new List<Contact>();
66        for (Account a : accounts) {
67            List<Contact> relatedContacts = contactsByAccount.get(a.Id);
68            if (relatedContacts != null) {
69                for (Contact c : relatedContacts) {
70                    c.MailingCity = a.BillingCity;
71                    contactsToUpdate.add(c);
72                }
73            }
74        }
75        
76        // ONE DML operation for all contacts
77        if (!contactsToUpdate.isEmpty()) {
78            update contactsToUpdate;
79        }
80        
81        // Result: 1 SOQL + 1 DML instead of N × M
82    }
83}

🏋️ Practice Exercise

Deep-Dive Exercises:

  1. Log into your Developer org and check which instance you're on (Setup > Company Information)
  2. Create a custom object and then use Tooling API to find how it's stored as metadata
  3. Write an Apex class that outputs all current governor limit values using the Limits class
  4. Design a process that would hit the 100 SOQL limit and then refactor it to use 1 query
  5. Research the Salesforce Trust site (trust.salesforce.com) — find your instance's uptime history
  6. Explain why Salesforce doesn't allow arbitrary SQL JOINs in SOQL
  7. Calculate the maximum number of records you can process in a single synchronous transaction
  8. Research how Salesforce handles schema changes in a multi-tenant database
  9. Investigate what happens when an org on your instance triggers a runaway process
  10. Compare Salesforce's multi-tenant model to AWS single-tenant (dedicated) instances

⚠️ Common Mistakes

  • Thinking each org has its own database — ALL orgs on an instance share the same physical database with logical data separation via OrgId

  • Ignoring governor limits during development because your dev org has small data — production might have millions of records being processed in bulk

  • Not understanding why SOQL is limited — it's not a limitation of Apex, it's protecting the shared infrastructure from expensive queries

  • Assuming your org runs in isolation — other orgs on the same instance compete for the same resources

  • Not monitoring instance health — production issues can be caused by Salesforce infrastructure, not just your code

💼 Interview Questions

🎤 Mock Interview

Mock interview is powered by AI for Multi-Tenant Architecture & Metadata-Driven Platform. Login to unlock this feature.

← PreviousCertification & Career Progression RoadmapNext →Standard & Custom Objects, Relationships