2.1 Multi-Tenant Architecture & Shared Resources

2.1 Multi-Tenant Architecture & Shared Resources

Quick Answer: Salesforce runs many customer organizations on shared infrastructure. Isolation is enforced by the platform (org boundaries, security, and metadata), not by giving each customer a private database server. Governor limits and bulk-safe coding protect that shared tenancy.

Why Multi-Tenancy Matters for Developers

Platform Developer I is not a general cloud-architecture exam, but multi-tenancy is the reason Apex, SOQL, and Lightning behave the way they do. Every design choice—where you put logic, how you query, whether you loop DML—sits on top of a multi-tenant runtime: many orgs share hardware and software while remaining logically isolated.

In a single-tenant world you might tune a dedicated database, open unlimited connections, and run long-running jobs without thinking about neighbors. On Salesforce you never own the metal. You share CPU, memory, database capacity, and API throughput with other tenants. The platform therefore enforces fair use through governor limits, transaction boundaries, and bulk processing patterns.

Shared resources (what you actually share)

These are not arbitrary “gotchas.” They are the multi-tenant protection layer. If one org’s poorly written trigger issued one SOQL per record across millions of imports, shared database capacity would suffer. Limits stop that before it happens.

Isolation: What “Shared” Does Not Mean

Multi-tenant does not mean customers can see each other’s data. Salesforce isolates:

• Data — Records belong to an org (and, within the org, to sharing/visibility rules).
• Metadata — Custom objects, fields, Apex classes, Lightning components, and configuration are scoped to the org.
• Identity and security — Users, sessions, OAuth clients, and permissions do not cross org boundaries.
• Customization runtime — Your Apex and declarative automation run only for your org’s requests.

Isolation is a platform guarantee. You do not implement “row-level multi-tenancy” yourself for other Salesforce customers. Exam questions that imply you manage physical server separation for each customer are wrong for native Lightning Platform development.

Exam trap: “Your own database server”

Classic wrong mental models:

• “Each Salesforce org has its own dedicated database server that only we can configure.”
• “We can raise SOQL/CPU limits by provisioning more hardware for our org.”
• “Multi-tenant means our Apex can freely share memory with other customers’ processes.”

Correct mental model:

• Orgs share multi-tenant infrastructure.
• Limits and isolation are software-enforced on that shared fabric.
• Scale and performance come from bulk-safe, limit-aware design, not from ordering a bigger private box inside Salesforce.

If a scenario requires unrestricted OS access, long-running custom compute, or a dedicated relational database you fully control, that work often belongs outside the core multi-tenant app (for example Heroku or another external system integrated via APIs)—not “give me my own Salesforce DB server.”

Metadata-Driven Platform

Salesforce is metadata-driven. Much of what looks like “application code” elsewhere is configuration the runtime interprets:

• Objects and fields define the schema without writing DDL scripts per tenant.
• Page layouts, Lightning record pages, and compact layouts shape the UI per profile/app.
• Validation rules, flows, and approval processes encode business logic declaratively.
• Security metadata (profiles, permission sets, sharing rules, FLS) gates access.

When you create a custom object or field, you are adding metadata the platform stores and applies across the shared infrastructure—not installing a unique database for your company. That is why schema changes are org-scoped, packageable, and deployable through change sets, Metadata API, or Salesforce DX, and why the same platform can host thousands of differently shaped orgs.

For developers, metadata-driven design means:

1. Prefer declarative features when they fully solve the requirement.
2. Treat schema and automation as first-class deliverables, not afterthoughts.
3. Expect runtime interpretation—behavior can change when metadata changes without recompiling “the whole product.”
4. Package and deploy thoughtfully so metadata moves safely between sandboxes and production.

Governor Limits as Multi-Tenant Protection

Governor limits are the exam’s favorite expression of multi-tenancy. They cap what a single Apex transaction (or async context) may consume. Typical categories you will reason about throughout the exam (exact numeric limits evolve by release; memorize the categories and patterns, and verify current numbers on official docs when coding):

• SOQL queries and SOQL rows retrieved
• DML statements and DML rows
• CPU time and heap size
• Callouts and callout time
• Email invocations, future calls, queueable depth, and other async ceilings

Limits apply per transaction (with separate, often higher, budgets for some async contexts). Crossing a limit throws a runtime exception and rolls back work that did not commit. That is intentional: better one transaction fails than one tenant starves neighbors.

Why bulkification matters

Salesforce does not guarantee one-record-at-a-time execution. Triggers, record-triggered flows that call Apex, bulk API loads, and many UI multi-save paths process sets of records—commonly up to 200 in a trigger context. Code written as:

for each record:
  query related data
  update one child

…will explode SOQL/DML counts under bulk load even if it “works” when a user clicks Save on a single record.

Bulkification means:

• Collect Ids and keys first.
• Query once into Maps/Sets.
• Perform DML once on lists.
• Write triggers and handler classes that behave correctly for 1 record and for 200.

Bulkification is not a style preference. It is how you stay within shared-resource limits when the platform batches work. Unbulkified code is a multi-tenant liability.

Transaction boundaries (developer lens)

A transaction groups work that succeeds or fails together and shares one set of governor counters. Understanding where a boundary starts and ends (user save, API request, queueable execute, batch execute, etc.) tells you how much budget you have and when static variables reset. Recursion and cascading updates can re-enter automation inside the same or related transactions—another reason bulk-safe, re-entrancy-aware design matters on a multi-tenant platform.

Designing With Shared Tenancy in Mind

Practical Platform Developer I habits:

1. Assume bulk. Always design Apex for lists, not single records.
2. Assume limits. Sketch SOQL/DML counts before writing nested loops.
3. Prefer set-based thinking. Maps keyed by Id are your friend.
4. Push work to the right tier. Declarative when possible; efficient Apex when needed; async when synchronous budgets are too tight; external platforms when the problem is not a multi-tenant CRM transaction.
5. Test at scale. Unit tests should cover bulk volumes (commonly 200 records) so limit failures appear in CI, not production.
6. Never invent private-server answers for native platform questions.

Scenario: data import weekend

A business imports 50,000 Contacts. Your before insert trigger queries Account by name inside a loop and updates a related custom object one row at a time. In the UI, creating one Contact works. On import, the job fails with too many SOQL queries or DML statements.

Root cause: single-record thinking on a multi-tenant bulk engine.
Fix: query Accounts once for the import set, map results, and DML once—bulkified design aligned with shared resources.

Scenario: “just give us more CPU”

A stakeholder asks to “turn up the server” because a synchronous screen action times out. On Salesforce you optimize the transaction (reduce queries, move heavy work async, slim the UI path), not provision a dedicated app server. That distinction is multi-tenancy in product form.

How This Domain Shows Up on the Exam

Expect questions that:

• Link governor limits to protecting multi-tenant resources
• Reject answers that assume a dedicated database server per customer
• Require bulk-safe trigger/class patterns
• Contrast platform capabilities with external systems when dedicated compute or OS control is required
• Treat metadata (objects, fields, automation config) as the unit of customization on shared infrastructure

If you keep one sentence in mind for this section: you share the platform, so you code for bulk work and fair-use limits while the platform isolates your data and metadata.

That mindset is the foundation for Apex, automation, UI, and testing topics later in the guide.