What Salesforce Tests in System Design

The system design round at Salesforce runs about 45 to 60 minutes. More often than you would expect, it happens inside Quip, Salesforce's own collaborative doc tool, rather than on a whiteboard. You type and talk through tradeoffs in a shared document. That format hints at what the round wants from you: a narrated argument, not a pretty diagram. The harder thing to plan around is that two Salesforce candidates rarely get the same prompt. One team hands you a CRM data model, another asks you to write SQL against a schema, a third runs a textbook "design Ticketmaster." Knowing which of those is coming changes how you prep.

The Salesforce angle

Salesforce is a federation of clouds, so the team you interview with picks the prompt. Sales Cloud, Service Cloud, Marketing, Commerce, the core Platform, plus acquired orgs like Slack, Tableau, and MuleSoft each run their own loops with their own habits. There is no single canonical Salesforce design question the way "design a rate limiter" is canonical elsewhere. Candidates report the full spread: shared-schema multi-tenancy and CRM modeling on the platform teams, classic distributed-systems HLD on the infra-flavored teams, and low-level object modeling almost anywhere. Ask your recruiter which team and which cloud the loop is for, because that answer tells you whether to drill the metadata-driven platform or a generic scalable service.

The round, and where it sits

The onsite is roughly four rounds across about half a day, virtual by default. The modal shape is two coding interviews, one system design, and one behavioral or hiring-manager round, though new-grad loops often trim design to something light or optional and senior loops add weight to it. Design depth scales hard with level. An AMTS or MTS candidate may see design folded into an object-modeling exercise. An SMTS gets a real high-level design with data modeling and read-write tradeoffs. An LMTS or above gets the open-ended platform-and-scale prompts. The grid below is the shape to expect. Salesforce publishes no question list, so read it as a steer rather than a syllabus.

• Format: 45 to 60 min, often in Quip. Conducted in a shared doc rather than a whiteboard on many teams, which rewards written, narrated tradeoffs over diagram polish. Candidates report being asked to revisit a choice and justify it on the spot, so reasoning transparency is weighted as heavily as the final architecture.
• Where it sits: One round in a ~4-round onsite. Modal loop is two coding, one system design, one behavioral or hiring-manager round. New-grad and AMTS loops may make design light or optional; SMTS and above carry a full design round.
• Team variance: Unusually high. Reported design prompts range from database and raw-SQL questions to CRM-modeling questions, team to team. The federation of clouds and acquisitions is why there is no one fixed prompt.
• Level skew: Object modeling low, platform high. AMTS and MTS lean toward low-level object modeling folded into the round. SMTS gets real HLD with data modeling. LMTS and above get open-ended platform and scale prompts such as a marketing-campaign system or a connection pool.

The three families of prompt

Reported prompts cluster into three families. The multi-tenant and CRM-platform shapes are the differentiated core, the ones where a Salesforce-flavored answer is visibly different from a generic one. Generic high-level designs show up too, the same Ticketmaster and TinyURL and distributed-scheduler prompts any big-tech loop uses, with no special Salesforce signal. And low-level object modeling appears more often here than at peer companies, a legacy of the Apex and Java OOP heritage. The bars show relative emphasis, not a published distribution. They sit close together on purpose: team variance keeps any single shape from dominating.

The low-level object-modeling prompts (parking lot, elevator, an LRU or a Premium question built as a class) overlap heavily with the coding interview. Prepare them in the object-modeling lesson, and treat this round as the place to show platform thinking. If a generic HLD lands, do not abandon the tenant lens. A multi-tenant Ticketmaster still partitions by org, still meters per-tenant load, and still earns the signal a generic answer leaves on the table.

The multi-tenant spine every platform answer shares

The Salesforce angle

Partition everything by tenant on one shared schema, and never reach for a database per customer. This is the single decision that separates a Salesforce answer from a generic SaaS answer. A single Salesforce instance, called a pod, runs one shared multi-tenant database. One physical schema holds thousands of customer orgs, around 8,000 per database across 50-plus pods. A metadata kernel reads each tenant's definitions at runtime and presents them a custom application, so adding a custom field never runs CREATE TABLE or ALTER TABLE. It inserts metadata rows. A candidate who proposes spinning up an isolated database for each tenant has answered a different question than the one Salesforce is asking. An interviewer who lives in this architecture will hear it immediately.

The data path below is the spine to carry into any platform prompt. A request arrives stamped with an OrgID. The metadata kernel resolves which virtual objects and fields the tenant has defined. A governor check guards the shared infrastructure, and the query rewriter turns a tenant's logical query into one that hits the generic physical tables. The reads land on pivot index tables to find candidate record IDs, then on the one enormous shared data table, both hash-partitioned by OrgID so a query only ever touches its own tenant's partition.

Read the path in chips. A request stamped with OrgID hits the metadata kernel, which resolves the tenant's virtual schema from the Universal Data Dictionary and passes a governor check. The query rewriter then turns it into SQL over the MT_Indexes pivot and the shared MT_Data table, returning a tenant-scoped result. The instinct to carry: OrgID is the partition key for everything, metadata replaces schema migrations, and governor limits are how shared infrastructure stays fair.

What the round rewards

The Salesforce angle

A limiter here is per-tenant fairness with governor limits, not a global token bucket. This is the Salesforce rate-limiting twist, and it carries real numbers you can name. Apex enforces hard per-transaction caps: 100 SOQL queries, 150 DML statements, 50,000 rows, 10 seconds of CPU. The API layer enforces a soft per-org daily limit instead: 100,000 calls plus 1,000 per user license on a rolling 24-hour window. It keeps processing until a system-protection threshold trips. A separate cap holds each org to 25 concurrent long-running requests. Hard versus soft, per-transaction versus per-org, concurrency versus volume: walking those distinctions is how you show you understand noisy-neighbor defense on shared infrastructure rather than a generic counter.

Two things help you more than they would at a typical loop. First, this architecture is genuinely documented. The multi-tenant internals, the governor limits, and the Platform Events bus all live on architect.salesforce.com, the developer docs, and Trailhead, so you can ground a claim in how Salesforce works instead of guessing. Use that. Second, the round prizes narrated tradeoffs. Candidates report interviewers asking them to revisit a choice and defend it, valuing the walk through alternatives over arriving at one correct answer. Make the reasoning explicit: why shared schema over schema-per-tenant, why a pivot index over indexing the flex table, why an ordered replayable log over fire-and-forget delivery.

The worked designs

Five designs follow. Each is a distinct shape, and each carries the multi-tenant signature so the set reads as Salesforce and not generic big-tech. Start with the multi-tenant platform: it is the fullest version of the spine above and the design no other guide in this catalog teaches.

Each design assumes the fundamentals from the System Design course: the scaling playbook for read and write paths. The toolbox covers when to reach for a log, a cache, a queue, or an index. The low-level object-modeling prompts (parking lot, elevator, a cache built as a class) live in the object-oriented design lesson, since they belong to the coding round more than this one.