Multi-Tenancy, Governor (Trust) Limits, Hyperforce & Data Residency in Salesforce

Introduction

Salesforce is multi-tenant at its core: many customers share the same runtime, database fabric, and services, while each org’s data and metadata stay logically isolated. To keep this shared environment fast and fair, Salesforce enforces governor (trust) limits—caps on resource usage at the transaction and org level. With Hyperforce, Salesforce runs on hyperscale clouds and lets customers choose the region where data resides to meet locality and compliance needs.

This guide ties those pillars together and shows how Developers, Admins, and Architects can design solutions that scale, comply, and perform.

1) Multi-Tenancy (what it is and why it matters)

Definition: Multiple orgs run on shared infrastructure; each tenant’s data and metadata are isolated.

Why it’s good

• Centralized patching and upgrades, no customer patch marathons

• Elastic scale and consistent release cadence

• Lower total cost of ownership

Design implications

• Code for neighbors: bulkify, avoid chatty loops, cache within the transaction

• Be retry-friendly: transient errors happen; design idempotent logic

• Think in batches: shape logic for lists, not single records

• Observe & tune: use logs, checkpoints, and event-level telemetry where available

Anti-patterns to avoid

• N+1 queries, per-record callouts, recursion without guards

• Unselective SOQL on large objects

• Doing everything synchronously “because it’s simpler”

2) Governor (Trust) Limits

Purpose: Prevent any single org/transaction from impacting others and keep the platform predictable.

Common categories (mostly per-transaction unless noted)

• CPU & Heap: total execution time and memory footprint

• SOQL & Rows: number of queries and rows retrieved

• DML & Rows: number of DML operations and records processed

• Callouts: count and total time; concurrency can also bite at the org level

• Async caps (org-wide): Queueable/Batch concurrency, daily async limits

• Messaging/Events: limits around Platform Events/CDC publishes and deliveries

Mindset

• Limits are design inputs, not obstacles.

• Prefer asynchronous processing for heavy work and I/O.

• Measure first, then optimize.

Patterns that pass limits

• Bulkify everything: operate on lists, not singles

• Selective SOQL: indexed filters, avoid leading wildcards and broad ORs

• Map-first logic: collect IDs → one query → map → enrich in memory

• One trigger per object: delegate to handlers; guard against recursion

• Cache inside the transaction: Maps, sets, lightweight memoization

• Push heavy work async: Queueable, Batch, Scheduled, Platform Events

3) Hyperforce

What it is: Salesforce deployed on major public clouds with region selection (e.g., EU, US).

Why it matters

• Data residency & compliance: keep data in-region

• Performance: lower latency by keeping users and data close

Developer experience

• Same APIs, metadata, and features

• Be mindful of region-aware endpoints, cross-region flows, and latency

• Align integrations and analytics pipelines with the org’s chosen region

4) Data Residency

Goal: Keep customer data within specific geographic boundaries to satisfy legal/contractual requirements.

Scope to consider (not just records)

• Primary storage, backups, and logs

• File content (attachments), search indexes, and caching layers

• Sandboxes, support exports, and downstream analytics

• Third-party integrations and ETL tools

Design moves that help

• Keep processing in-region where possible

• Aggregate/anonymize before cross-region use

• Encrypt sensitive fields (e.g., Shield) and minimize PII footprint

• Document data flows end-to-end for audits

5) Real-World Patterns & Use Cases

• Global retailer: EU org on Hyperforce Frankfurt; US analytics consumes only aggregated, non-PII metrics.

• Fintech: Shield Encryption + Named Credentials; reconciliation runs in batches to avoid CPU/row spikes.

• ISV: Event-driven architecture with Platform Events; idempotent consumers guarantee safe at-least-once delivery.

Bulkified Trigger + Service (avoid governor pitfalls)

Best practices shown: one trigger, bulk SOQL, no SOQL/DML in tight loops, minimal synchronous work.

// Trigger: one per object → delegate to handler
trigger OrderTrigger on Order__c (after insert, before update) {
    if (Trigger.isAfter && Trigger.isInsert)
        OrderTriggerHandler.afterInsert(Trigger.new);
    if (Trigger.isBefore && Trigger.isUpdate)
        OrderTriggerHandler.beforeUpdate(Trigger.new, Trigger.oldMap);
}

public class OrderTriggerHandler {
    public static void afterInsert(List<Order__c> records) {
        // Bulk query related data in ONE roundtrip
        Set<Id> acctIds = new Map<Id, Order__c>(records).keySet();
        Map<Id, Account> accts = new Map<Id, Account>(
            [SELECT Id, Tier__c FROM Account WHERE Id IN :acctIds]
        );
        for (Order__c o : records) {
            o.Priority__c = (accts.get(o.Account__c)?.Tier__c == 'Gold') ? 'High' : 'Normal';
        }
        // DML in bulk (before insert/update would avoid this DML)
    }

    public static void beforeUpdate(List<Order__c> news, Map<Id, Order__c> olds) {
        // Avoid work when nothing relevant changed
        for (Order__c n : news) {
            Order__c o = olds.get(n.Id);
            if (n.Status__c == o.Status__c) continue;
            // ...lightweight field logic only; push heavy work to async
        }
    }
}

Asynchronous Processing for Limits (Queueable + Idempotency)

Why: Move heavy I/O out of the transaction; enable safe retries.

public class ShipOrdersQueueable implements Queueable, Database.AllowsCallouts {
    @AuraEnabled public Set<Id> orderIds;
    public ShipOrdersQueueable(Set<Id> ids) { orderIds = ids; }

    public void execute(QueueableContext ctx) {
        // Correlation key for idempotency (avoids duplicates on retries)
        String corr = 'ship-' + DateTime.now().getTime();

        List<Order__c> orders = [SELECT Id, Status__c FROM Order__c WHERE Id IN :orderIds LIMIT 2000];
        // Chunk external callouts to stay under callout and CPU limits
        for (List<Order__c> batch : (List<List<Order__c>>) System.chunk(orders, 50)) {
            // call WMS via Named Credential
            HttpRequest req = new HttpRequest();
            req.setEndpoint('callout:wms/ship');
            req.setMethod('POST');
            req.setHeader('Idempotency-Key', corr);
            req.setBody(JSON.serialize(batch));
            new Http().send(req);
        }
    }
}

// Example: choose endpoint by org's Hyperforce region
public class RegionEndpoints {
    public static String base() {
        String region = UserInfo.getDefaultCurrency(); // placeholder for your region source
        // Better: store region in Custom Setting/Metadata or call a platform API
        return (region == 'EUR') ? 'callout:eu_analytics' : 'callout:us_analytics';
    }
}

HttpRequest req = new HttpRequest();
req.setEndpoint(RegionEndpoints.base() + '/ingest');
req.setMethod('POST');
req.setHeader('Content-Type','application/json');
req.setBody(JSON.serialize(payload));
HttpResponse res = new Http().send(req);