How do you architect Apex code for orgs with Large Data Volumes (LDV)?

LDV is when objects have millions to hundreds of millions of records. Standard Apex patterns break.

Read patterns:

1. Selective queries are mandatory. SOQL must filter on indexed fields. Salesforce auto-indexes Id, Name, foreign keys. Custom Indexes can be requested via Salesforce Support.
2. Use `Database.QueryLocator` for >50k rows — iterates lazily, doesn't materialise the full result set.
3. Pagination via `LIMIT`/`OFFSET` is anti-pattern past 2000 rows — Salesforce has a hard OFFSET cap of 2000. Use Last-seen Id pagination instead:

apex List<Account> page = [SELECT Id, Name FROM Account WHERE Id > :lastSeenId ORDER BY Id LIMIT 1000];

1. Avoid GROUP BY on huge data — aggregate query row limit is 2000. Use external warehousing (Snowflake/BigQuery) for analytics over millions.
2. Skinny Tables — for very high-frequency reads on standard objects, Salesforce can provision a denormalised Skinny Table. Request via Support.

Write patterns:

1. Batch Apex for any bulk operation over 10k records. Each execute() chunk is its own transaction.
2. Bulk-safe DML — bulkify mercilessly. The 200-record-per-trigger pattern that's a guideline at 100k records is a requirement at 100M.
3. Defer Sharing Calculations during massive ownership changes. Setup -> Defer Sharing Calculations.
4. Avoid Roll-Up Summary fields on LDV objects — they recalculate on every child change. Use periodic batch jobs to refresh aggregate fields instead.

Integration patterns:

1. Bulk API 2.0 for inbound loads — never single-record REST calls for high volume.
2. Change Data Capture for outbound replication — push to Snowflake/BigQuery via middleware.
3. External objects via Salesforce Connect for "we need to see it but not store it" cases.
4. Big Objects for archive — billions of rows of historical data, queryable by indexed key.

Sharing model:

1. Avoid Private OWD on LDV objects if business allows — sharing recalc takes hours.
2. Apex Managed Sharing with surgical RowCause — finer-grained than Sharing Rules; lower recalc cost.
3. Don't add sharing rules carelessly — each rule increases recalc time.

Testing:

1. Full Sandbox is mandatory for performance testing. Dev sandbox with 100 records doesn't reveal LDV issues.
2. Apex tests with 200+ records to confirm bulk safety.
3. Production-like data volume testing — load realistic data to a Full sandbox before launch.

Monitoring:

1. Event Monitoring — slow query logs.
2. System Overview — row counts approaching LDV thresholds.
3. Alerting when sharing recalc queues build up.

LDV-aware design is architect-level work. Many decisions made early (OWD = Private, Roll-Up Summaries on hot objects) are extremely expensive to reverse at scale. Plan for LDV during initial design, not in remediation.