Design Salesforce CRM

Problem Statement & CRM Control Plane

Salesforce interviewers expect you to own the multi-tenant CRM kernel: leads, accounts, opportunities, cases, and the automation that ties them together — all without collapsing into one monolithic database per customer. The defining constraint is that tens of thousands of customer orgs share the same physical infrastructure, yet each must feel like it has a private database. Every architectural decision flows from that single tension: shared infrastructure, hard tenant isolation.

The control plane has three non-negotiable responsibilities. First, org isolation: every record carries an org_id, and it is the leading component of every shard key, every index, and every query predicate — a query that forgets it is a cross-tenant data leak, the one unrecoverable failure. Second, the permission boundary: sharing rules and field-level security (FLS) are evaluated before any record leaves the API tier, so a user physically cannot retrieve a row, or even a single field, they are not entitled to. Third, safe automation: triggers and Flows fire on record changes, and they must be idempotent, because at-least-once delivery and bulk operations guarantee they will sometimes run twice.

The scale that makes this hard: on the order of 3M daily active users, 8B+ records, read p99 around 120ms and write p99 around 250ms, against a few thousand API requests per second metered by per-org token buckets. The numbers rule out the naive answers — you cannot give every org its own database (operationally impossible at that count), and you cannot put them all in one unpartitioned table (a single org's quarter-close bulk update would starve its neighbors' IOPS). The shard key below — org plus a user bucket — is the primitive the whole design rests on.

Key Highlights

•Shared infrastructure, hard tenant isolation — every decision flows from that one tension
•org_id leads every shard key, index, and query predicate; a query that forgets it is a data leak
•Sharing rules + FLS are enforced before any record (or field) leaves the API tier
•Triggers and Flows must be idempotent — bulk ops and at-least-once delivery guarantee double-fires

1 from dataclasses import dataclass 2 3 @dataclass(frozen=True) 4 class OrgContext: 5 org_id: str 6 user_id: int 7 8 # org_id leads the key so a tenant's rows colocate on one shard 9 def shard_key(self) -> str: 10 return f"{self.org_id}:{self.user_id % 512}"

Problem Statement & CRM Control Plane

Problem Statement & CRM Control Plane

Key Highlights

Org-Scoped Shard Key

Section Rescue Kit

1	from dataclasses import dataclass
2
3	@dataclass(frozen=True)
4	class OrgContext:
5	org_id: str
6	user_id: int
7
8	# org_id leads the key so a tenant's rows colocate on one shard
9	def shard_key(self) -> str:
10	return f"{self.org_id}:{self.user_id % 512}"