Performance, Scalability, and Large Data Volumes
Performance, Scalability, and Large Data Volumes
This domain tests whether you can predict what breaks first as data and concurrency grow, and fix it with design rather than tuning after go-live.
Query performance
Selectivity is everything. Indexed fields include Id, Name, OwnerId, lookup and master-detail fields, external IDs, unique fields, CreatedDate, SystemModstamp, and custom indexes requested through Support. Use the Query Plan tool: a leading cost near or below 1.0 is healthy; a full table scan is a defect. Avoid negative filters (!=, NOT IN), leading wildcards, null comparisons, and filters on non-deterministic formula fields.
Limits that shape design
SOQL returns at most 50,000 rows per transaction. Heap is 6 MB synchronous and 12 MB asynchronous. Synchronous callout timeout maximum is 120 seconds. These numbers drive batching, field selection, and async architecture.
Large data volumes
- Data skew: ownership skew (one owner holding a large share of an object's records) and lookup skew cause lock contention and slow sharing recalculation. Mitigate by redistributing ownership and deferring sharing calculation during bulk loads.
- Skinny tables, provisioned by Salesforce Support, speed queries on wide objects.
- Big Objects hold archive data; Async SOQL queries them.
- Bulk API serial mode reduces lock contention during large loads.
- Keyset pagination (
WHERE Id > :lastId ORDER BY Id) beats OFFSET, which degrades with depth.
Worked example
A dashboard filters 12 million orders by status and date. Status is not indexed; CreatedDate is. Adding a filter on CreatedDate helps, and a custom index on status improves selectivity - but a dashboard aggregating 12 million rows is still slow. The real fix is pre-aggregation: a nightly Batch Apex job writes daily summary records, and the dashboard reads thousands of rows instead of millions. Indexes reduce scan cost; aggregation reduces the question.
Traps that cost marks
OFFSET pagination deep into a result set. Selecting every field. Batch sizes so large they hold locks. Assuming an index fixes a badly shaped query. Ignoring skew until sharing recalculation times out. Designing synchronous processing for volumes that need queues.
Key points
- Query Plan cost near 1.0; table scans are defects.
- 50,000 SOQL rows, 6/12 MB heap, 120-second callout ceiling.
- Ownership and lookup skew cause locking and sharing problems.
- Keyset pagination replaces deep OFFSET.
- Pre-aggregate for dashboards rather than indexing everything.