35 Epic Salesforce Developer Scenarios (Post 3)
35 Epic Salesforce Developer Scenarios
Post 3 (FINAL): DevOps Disasters, Architecture Design, Production War Stories & High-Scale Systems
35
Final Questions
Q71–Q105
Epic Scenarios
105 Total
Complete Series
100% Free
No Signup
This is it, bro. 105 scenarios complete. You've crushed production debugging (Post 1), mastered advanced patterns (Post 2), now it's time for the war stories. These final 35 questions are the conversations that happen in senior team leads' 1-on-1s: "How would you handle a data migration that corrupts 10M records? What's your deployment strategy when the org is handling 500M+ records? Tell me about a production incident you caused and how you fixed it."
35 Questions in 5 Epic Categories:
• 🔧 DevOps & Deployment Disasters (Q71–Q77)
• 🏗️ Architecture & System Design Patterns (Q78–Q84)
• ⚡ Real Production War Stories (Q85–Q91)
• 💰 High-Scale System Design (Q92–Q98)
• 🚀 Performance Optimization & Limits (Q99–Q105)
Pair with complete 105-question series: Post 1 (Q1–Q35) • Post 2 (Q36–Q70) • Agentforce Course • Practice Zone (27 Quizzes, 2,244 MCQs)
DevOps & Deployment Disasters
7 Questions71
Data Migration: 10M Records, Wrong Field Mapped — Rollback Plan?
Advanced
Direct Answer
If detected within 15 days: restore from Recycle Bin (bulk delete, Recycle Bin keeps 15 days, then restore original). If beyond 15 days: use backup service (3rd party) or Accept data loss and re-map field correctly. For future: data validation step BEFORE production insert (sample 100 records, compare source vs destination). Use batch with validation step + feature flag to enable/disable.
Why?
Data migrations are high-risk. A single wrong field mapping corrupts 10M records instantly. Salesforce Recycle Bin keeps deleted records for 15 days (your safety net). Beyond that, you need a backup service (Data Cloud, third-party backup vendor). Without validation, you don't know data is wrong until users discover it days later (expensive, trust damage).
Code Example
// ✓ CORRECT — Validation before production insert
global class DataMigrationBatch implements Database.Batchable {
global Database.QueryLocator start(Database.BatchableContext bc) {
return Database.getQueryLocator('SELECT Id, Name FROM Legacy_Order__c ORDER BY Id');
}
global void execute(Database.BatchableContext bc, List<sObject> scope) {
List<Order__c> ordersToInsert = new List<Order__c>();
List<MigrationError__c> errors = new List<MigrationError__c>();
for (Legacy_Order__c legacyOrder : (List<Legacy_Order__c>)scope) {
// Validation: check field mapping is correct
if (String.isBlank(legacyOrder.Name)) {
errors.add(new MigrationError__c(
ErrorMessage__c = 'Legacy Name is blank',
SourceId__c = legacyOrder.Id,
Status__c = 'Validation Failed'
));
continue; // Skip this record
}
Order__c newOrder = new Order__c(
Name = legacyOrder.Name,
ExternalId__c = legacyOrder.Id, // For idempotency
MigrationBatch__c = DateTime.now().format('yyyy-MM-dd')
);
ordersToInsert.add(newOrder);
}
if (!ordersToInsert.isEmpty()) {
insert ordersToInsert;
}
if (!errors.isEmpty()) {
insert errors; // Log validation failures for review
}
}
global void finish(Database.BatchableContext bc) {
// Check error count
Integer errorCount = [SELECT COUNT() FROM MigrationError__c WHERE Status__c = 'Validation Failed'];
if (errorCount > 0) {
// PAUSE MIGRATION: errors detected, review before proceeding
System.debug('❌ Migration halted: ' + errorCount + ' validation errors found');
}
}
}
Rollback Strategy
- Detected within 15 days: Bulk delete all migrated records (mark by MigrationBatch timestamp). They go to Recycle Bin. Restore from Recycle Bin if needed.
- Detected after 15 days: Check if backup service has snapshot (3rd party). If yes, restore. If no, accept data loss, fix mapping, re-run migration.
- Prevention for next time: Add validation step before INSERT. Log validation errors to MigrationError__c object. Review errors before marking migration as "Complete."
- Feature flag approach: Batch inserts with flag OFF. Enable flag only after manual review. Rollback = disable flag, manual delete, investigate.
Real World Example
XYZ Company: Migrated 10M legacy orders. Field mapping was wrong: Amount mapped to Quantity (orders now show ₹50,000 quantity instead of ₹50,000 amount). Discovered 3 weeks later by finance team. Recycle Bin was empty (past 15 days). No backup service. Lost 3 weeks of data, had to re-migrate from source.
What should have happened: Before production migration, validate 100 sample records. Compare source vs destination. Pause migration if validation fails. Log all failures for manual review. Only proceed after validation passed 100%. Store backup snapshots in Data Cloud or third-party service.
Key Points
- Data migrations are high-risk. Validation step BEFORE production insert is critical.
- Recycle Bin = 15-day safety net. Beyond that, backup service required.
- Feature flag: batch disabled by default, enabled only after manual review.
- Log validation failures to custom object (MigrationError__c). Review before proceeding.
- Test migration on sample data first (1% of prod), validate, then full production.
"Data migrations are high-risk. Validate before INSERT. Log failures to custom object. Recycle Bin saves you for 15 days, backup service for longer. Feature flag to control rollout."
72
Managed Package Upgrade: Breaking Change, Existing Customization Breaks
Advanced
Direct Answer
Managed package update can remove fields/classes (breaking change). Your custom code breaks if it references removed items. Solution: (1) Test upgrade in sandbox first (catches breaks), (2) Update custom code to handle new package API, (3) Deploy fix to prod, (4) Then upgrade package in prod. Never upgrade package in prod without sandbox testing.
Key Points
- Managed package upgrade can break your custom code (remove fields, classes, APIs).
- Test upgrade in sandbox first (catches 90% of breaking changes).
- Update your custom code to new package API before upgrading prod.
- Deploy fixes to prod, then upgrade package. Never reverse order.
"Test package upgrades in sandbox first. Update your custom code to new package API. Deploy fixes to prod, then upgrade package. Test before touching prod."
73
Deployment Validation: Custom Field on Deleted Object — Deploy Fails
Medium
Direct Answer
Custom fields on deleted objects can't exist. Deployment fails if you include custom field whose parent object was deleted. Solution: (1) Remove field from deployment package, (2) Restore deleted object in prod (if available in Recycle Bin), (3) Or just deploy without the field (it's orphaned). Check deployment error for exact object/field name.
Key Points
- Deployment validates metadata exists in destination. Deleted objects fail validation.
- Check Recycle Bin: restore deleted object, then redeploy field.
- Or remove field from deploy (it's orphaned, no longer needed).
"Custom fields on deleted objects fail deployment. Restore deleted object from Recycle Bin or remove field from deployment. Always check error message for exact object name."
74
Environment Parity Issue: Works in Sandbox, Fails in Production
Advanced
Direct Answer
Sandbox != production. Common causes: (1) Org limits (sandbox limits ≠ prod), (2) Data scale (sandbox has 10k records, prod has 10M), (3) Trigger order differs (sandboxes sometimes skip triggers), (4) Custom settings have different values (test override vs prod real values), (5) Managed packages at different versions. Solution: Test with production-scale data in sandbox, verify org limits match, check custom settings values.
Key Points
- Sandbox is copy of prod at point-in-time (data, config snapshot). Changes drift over time.
- Test with prod-scale data (if prod has 10M, load 10M to sandbox).
- Check custom settings: sandbox may have test values, prod has real values.
- Verify trigger order: sometimes sandbox skips certain triggers (org config issue).
"Sandbox drifts from prod. Test with production-scale data. Verify custom settings values. Check org limits (API calls, batch count, etc.). Trigger order may differ."
75
Deployment Blocking Issue: Dependency Loop Between Components
Medium
Direct Answer
Metadata can't have circular dependencies: Flow A calls Flow B, Flow B calls Flow A = deployment fails. Solution: Break loop by introducing intermediate flow or by restructuring logic. Refactor: A → shared utility → B (no circular path).
Key Points
- Circular dependencies fail deployment (A depends on B, B depends on A).
- Break loop with intermediate component or refactor logic.
- Salesforce metadata API detects these during validation.
"Circular dependencies fail deployment. Break loops by introducing intermediate component. A → Utility → B (no circularity). Refactor before deploy."
76
Parallel Deployments: Two Teams Deploy Same Code, Conflict?
Medium
Direct Answer
Salesforce queues deployments (doesn't run parallel). Only one deploy can be in progress at a time. If two teams deploy simultaneously, second deploy queues and waits. Once first finishes, second auto-starts. If first deploy has issues, second deploy may fail due to changed metadata. Solution: Coordinate deploys, use single deployment pipeline, merge PRs before deploy.
Key Points
- Salesforce queues deployments (serial, not parallel).
- Second deploy may fail if first deploy changed same metadata.
- Solution: deployment pipeline (one deploy at a time), coordinate teams.
"Salesforce queues deployments (serial). Second deploy may fail if first changed metadata. Coordinate teams, use single pipeline, merge PRs before deploy."
77
Rollback Without Redeploy — Can You Undo Code in Production?
Medium
Direct Answer
No native rollback in Salesforce. Options: (1) Redeploy previous code (slow, ~10 min), (2) Disable via feature flag (instant, code stays deployed), (3) Modify logic at runtime (Custom Setting toggle, instant). Best practice: feature flags for instant rollback. Redeploy for actual code removal (rare, typically only for cleanup).
Key Points
- No native rollback. Options: redeploy old code, disable via flag, toggle Custom Setting.
- Feature flags = instant rollback (code enabled/disabled, not deployed/undeployed).
- Redeploy takes ~10 min. Feature flag toggle takes <1 sec.
"No native Salesforce rollback. Use feature flags for instant disable. Redeploy old code if actual code removal needed (slow, ~10 min)."
Architecture & System Design Patterns
7 Questions78
Multi-Org Architecture: How to Sync Data Across Two Salesforce Instances?
Advanced
Direct Answer
Two Salesforce instances = two separate databases (can't join via SOQL). Architecture: REST API polling or webhooks to sync records. Org A (source) publishes events or provides REST endpoint. Org B (subscriber) polls or listens for webhooks, upserts records locally. Challenge: eventual consistency (data may be out-of-sync for 1-10s). Solution: Use idempotency key + queue pattern (Platform Events, webhook dead letter queue).
Key Points
- Multi-org requires inter-org API calls (REST, SOAP, Platform Events).
- Polling (org B queries org A every 5 min) vs Webhooks (org A pushes to org B).
- Idempotency key + queue pattern prevents duplicate syncs.
- Expect eventual consistency (1-10s latency between orgs).
"Multi-org sync via REST API polling or webhooks. Org A publishes, Org B subscribes. Use idempotency keys + queue pattern. Accept eventual consistency (1-10s latency)."
79
Analytics Architecture: Salesforce Analytics vs. External BI Tool?
Advanced
Direct Answer
Salesforce Analytics (CRM Analytics): real-time, built-in, limited to Salesforce data. External BI (Tableau, Power BI, Looker): connects to multiple sources (Salesforce, DW, APIs), more flexibility, higher cost. Choose based on: (1) Data source diversity (multi-source = external BI), (2) Real-time requirement (Salesforce analytics = real-time, external = batch), (3) Budget (internal = cheaper, external = costly).
Key Points
- Salesforce Analytics: real-time, built-in, Salesforce-only data.
- External BI: multi-source, flexible, higher cost, batch latency.
- Hybrid: use Salesforce Analytics for internal reporting, external BI for enterprise insights.
"Salesforce Analytics = real-time, built-in, Salesforce-only. External BI = multi-source, flexible, costly. Choose based on data diversity and real-time needs."
80
Event-Driven Architecture: Platform Events vs. Custom Metadata vs. Queueable?
Advanced
Direct Answer
Platform Events: async pub-sub, decouples triggers, ~1-10s latency, built for real-time events. Queueable: async processing, chains up to 5 deep, 3600s timeout, ordered execution. Custom Metadata: config/lookup data, no event model, use for feature flags/settings. Choose: Events for notifications (order placed), Queueable for sequential processing (validate → pay → ship), Custom Metadata for static config.
Key Points
- Platform Events: pub-sub, async, 1-10s latency, scalable.
- Queueable: ordered, chainable (5 deep), 3600s timeout, best for workflows.
- Custom Metadata: static config, no event model, feature flags.
"Platform Events for notifications (pub-sub), Queueable for sequential workflows (chainable), Custom Metadata for static config. Choose based on interaction pattern."
81
Governor Limits Hitting: Batch Job Times Out at 300k Records
Advanced
Direct Answer
Batch process 300k records, hits 10k SOQL or 10k DML limit mid-job. Solution: (1) Reduce batch scope (200 records instead of 2000), (2) Optimize SOQL (fewer queries per record), (3) Chain multiple batches via Queueable, (4) Use partial failure mode (Database.update allOrNone=false to process failures separately).
Key Points
- Batch size = records processed per execute(). Smaller batch = less SOQL/DML used.
- Optimize SOQL: one query per batch, use Map lookups instead of queries in loop.
- Chain batches (finish() enqueues next batch). Each batch has fresh 10k limit.
- Use allOrNone=false: partial success, log failures, continue processing.
"Batch hitting governor limits: reduce batch scope, optimize SOQL (1 query per batch), chain batches (finish enqueues next), use allOrNone=false for partial success."
82
Distributed Processing: How to Split Large Job Across Multiple Orgs?
Advanced
Direct Answer
Large job (1B records) can't fit in single org. Architecture: (1) Split records by ID range (Org A: IDs 0-250M, Org B: 250M-500M, etc.), (2) Each org processes independently (parallel), (3) Aggregate results externally. Challenge: maintaining ID uniqueness across orgs. Solution: Use external UUID or prefix IDs by org (Org A prefix: AAA, Org B: BBB).
Key Points
- Split by ID range or external key across orgs.
- Each org processes independently (true parallelism).
- Aggregate results externally (data warehouse, API gateway).
- Maintain ID uniqueness (prefix by org or use UUID).
"Split large jobs by ID range across orgs. Each processes independently. Aggregate externally. Maintain ID uniqueness via prefixes or UUID."
83
Caching Strategy: What Should Be Cached, What Should Not?
Medium
Direct Answer
Cache: lookup data (RecordTypes, Profiles, Picklists — changes rare). Don't cache: record data (Account, Order — changes frequently). In-memory cache (static Map) is fast (0ms) but risky if data changes. Use cache invalidation (expire after X seconds or on trigger). For frequently-changing data, accept query cost or use database indexes instead.
Key Points
- Cache: static data (RecordTypes, Profiles). Don't cache: transactional data (Orders, Accounts).
- Cache invalidation strategy: TTL (time-to-live) or event-driven (trigger clears cache).
- Static Map cache persists for entire transaction. Risky if data changes mid-transaction.
"Cache static data (RecordTypes). Don't cache transactional data (Orders). Implement cache invalidation (TTL or event-driven). Static cache persists entire transaction."
84
Microservices Pattern in Salesforce: How to Build Loosely Coupled Systems?
Advanced
Direct Answer
Microservices = independent services communicating via APIs. In Salesforce: create separate org per service (Order Service, Payment Service, Shipping Service). Each owns its data, exposes REST API. Communicate via webhooks (async) or REST calls (sync). Benefit: teams work independently, services scale separately, failure isolation (payment service down ≠ order service down).
Key Points
- Separate org per service (Order, Payment, Shipping).
- Each service owns its data, exposes REST API.
- Communicate via webhooks (async) or REST (sync).
- Failure isolation: service down ≠ org down.
"Microservices: separate org per service. Each owns data, exposes API. Communicate via webhooks/REST. Failure isolation protects system from cascading failures."
Real Production War Stories
7 Questions85
War Story: Trigger Loop Cascaded to Entire Database (3M Records Updated Unintentionally)
Advanced
Direct Answer
OrderTrigger updated Account before-insert. Account trigger updated Order after-insert. Two-way loop, recursion guard was Set<Id> but static variable wasn't cleared (persisted from previous test runs). In prod, 1 order insert cascaded to 3M order updates. Root cause: recursion guard not effective (Set persisted), no DML limit check, no feature flag to disable. Learned: (1) Use static Boolean recursion guard, (2) Check DML limit before update, (3) Feature flag to disable dangerous logic.
Key Points
- Recursion guard (Set<Id>) can fail if static variable persists unexpectedly.
- Always check DML limit before bulk updates (Limits.getDMLStatements()).
- Feature flag to kill dangerous logic instantly (disable without redeploy).
- Test with fresh sandbox (clear static variables from previous tests).
"War story: trigger loop updated 3M records. Cause: recursion guard didn't work + no DML limit check. Fix: use Boolean guard, check DML limit, feature flag to disable."
86
War Story: Batch Job Consumed All API Quota in 2 Hours (30k API Calls)
Advanced
Direct Answer
Batch job called external API 30k times (1 call per record). External API has 1k call/hour quota. Batch consumed 30k in 2 hours = quota exhausted, remaining batch calls failed. Root cause: no rate limiting, no batching of API calls, no queue mechanism to spread calls over time. Learned: (1) Batch API calls (send 100 records per call), (2) Queueable queue for rate limiting (1 call per Queueable, serialized), (3) Check API quota before deploying, (4) Have fallback (store call in queue, retry next day).
Key Points
- API quota exhaustion = batch jobs hang. No built-in rate limiting.
- Queueable queue for serialized, rate-limited API calls.
- Batch API calls: send 100 records per call (reduce call count 100x).
- Dead Letter Queue for failed calls (retry when quota refreshes).
"War story: batch consumed all API quota (30k calls). Fix: Queueable queue for rate limiting, batch API calls (100/call), Dead Letter Queue for retries."
87
War Story: Deployment Broke Production, Feature Flag Didn't Help (Hard-coded True)
Advanced
Direct Answer
Feature flag was added but hard-coded to TRUE in code (if (true) { dangerousLogic(); }). So flag value didn't matter — logic always executed. Production broke. Learned: (1) Never hard-code flag value, (2) Always read from Custom Metadata / Custom Setting, (3) Test with flag OFF to verify logic disables, (4) Code review must check for hard-coded booleans.
Key Points
- Feature flags are only useful if they're NOT hard-coded.
- Always read from Custom Metadata/Setting at runtime.
- Test with flag OFF: verify logic is disabled (don't skip test if feature OFF).
- Code review: check for hard-coded true/false in conditional logic.
"War story: feature flag was hard-coded TRUE. Logic always ran, flag was useless. Never hard-code flags. Always read from Custom Metadata. Test with flag OFF."
88
War Story: SOQL Query Wasn't Using Index, Took 45 Seconds (Should Be <1s)
Medium
Direct Answer
Custom index existed but SOQL wasn't using it (query optimizer chose full table scan). Reason: query joined on non-indexed field or OR condition made index unusable. Solution: (1) Use SOQL Analyzer to see which index is used, (2) Rewrite query to match index field order, (3) Update statistics (Setup > Indexes > Update Statistics), (4) Remove OR conditions if possible (use IN clause instead).
Key Points
- Index exists ≠ index is used. Query optimizer may choose not to use it.
- SOQL Analyzer shows which index is used (Setup > Indexes).
- Update Statistics if index is ignored (may recalculate cost).
- Query field order matters: if index is (A, B), WHERE A=x AND B=y uses index. WHERE B=y AND A=x may not.
"War story: index wasn't used (query took 45s). Fix: SOQL Analyzer to verify index usage, match field order, update statistics, avoid OR conditions."
89
War Story: Sandbox Data Got Deleted During Refresh, Lost 2 Weeks of Testing
Medium
Direct Answer
Sandbox refresh copies prod data to sandbox (clears old sandbox data). Testing data was lost. Root cause: no backup of sandbox before refresh. Learned: (1) Back up sandbox test data before refresh (export via Data Loader), (2) Use separate dedicated test sandbox (don't refresh it), (3) Data Cloud backup for critical data, (4) Refresh schedule: coordinate with team.
Key Points
- Sandbox refresh = clears old data, copies prod snapshot. Test data is lost.
- Back up critical sandbox data before refresh (Data Loader export).
- Dedicate one sandbox for testing (don't refresh frequently).
- Coordinate refresh schedule with team (notify before refresh).
"War story: sandbox refresh deleted 2 weeks of test data. Fix: back up before refresh, dedicate test sandbox, coordinate refresh schedule with team."
90
War Story: Production Deployment Took 6 Hours (Validation Never Finished)
Medium
Direct Answer
Deploy to production with 500k records matching a trigger. Validation had to recompile trigger against 500k records = 6 hour wait. Root cause: no test data limit check during validation. Learned: (1) Always validate in sandbox first (catches issues before prod deploy), (2) Use deployment tool with background validation (Copado, Flosum), (3) Archive old test data from prod, (4) Validate during off-hours if possible.
89
War Story: Sandbox Data Got Deleted During Refresh, Lost 2 Weeks of Testing
Medium
Direct Answer
Sandbox refresh copies prod data to sandbox (clears old sandbox data). Testing data was lost. Root cause: no backup of sandbox before refresh. Learned: (1) Back up sandbox test data before refresh (export via Data Loader), (2) Use separate dedicated test sandbox (don't refresh it), (3) Data Cloud backup for critical data, (4) Refresh schedule: coordinate with team.
Key Points
- Sandbox refresh = clears old data, copies prod snapshot. Test data is lost.
- Back up critical sandbox data before refresh (Data Loader export).
- Dedicate one sandbox for testing (don't refresh frequently).
- Coordinate refresh schedule with team (notify before refresh).
"War story: sandbox refresh deleted 2 weeks of test data. Fix: back up before refresh, dedicate test sandbox, coordinate refresh schedule."
90
War Story: Production Deployment Took 6 Hours (Validation Never Finished)
Medium
Direct Answer
Deploy to production with 500k records matching a trigger. Validation had to recompile trigger against 500k records = 6 hour wait. Root cause: no test data limit check during validation. Learned: (1) Always validate in sandbox first (catches issues before prod deploy), (2) Use deployment tool with background validation (Copado, Flosum), (3) Archive old test data from prod, (4) Validate during off-hours if possible.
Key Points
- Prod validation can hang if deployment is large (triggers, many records).
- Always validate in sandbox first. Sandbox validation is fast (few records).
- Use deployment tool with background validation (Copado, Flosum).
- Archive old test data from prod (reduce validation time).
"War story: prod deploy validation hung 6 hours. Fix: validate in sandbox first, archive old data, use background validation tools."
91
War Story: Code Coverage Dropped Below 75% After Merge, Deploy Blocked
Medium
Direct Answer
Developer merged code without tests (new class with 0% coverage). Org-wide coverage dropped from 76% to 74% (below 75% threshold). Deployment blocked. Root cause: no pre-commit code review, no CI/CD gate to enforce test coverage. Learned: (1) Pre-commit hooks to check coverage, (2) CI/CD pipeline fails if coverage < 75%, (3) Code review must check test coverage alongside logic, (4) Each new class must have 80%+ coverage.
Key Points
- Org-wide coverage must be 75%+. New code can drop overall coverage below threshold.
- Pre-commit hook: check coverage before commit to repo.
- CI/CD gate: deployment fails if coverage < 75%.
- Code review: check test coverage alongside logic review.
- Target 80%+ coverage per class (buffer for org-wide threshold).
"War story: coverage dropped below 75%, deploy blocked. Fix: pre-commit coverage check, CI/CD gate, code review includes coverage validation."
High-Scale System Design (100M+ Records)
7 Questions92
Design: 500M Salesforce Records. How Would You Scale?
Advanced
Direct Answer
500M records in single org = hitting storage limits (max 1B records). Architecture: (1) Archive old data (move to Data Cloud or external data warehouse), (2) Split across multiple orgs (Org A: current year, Org B: last year), (3) Query via Data Cloud (unified query across orgs), (4) Aggregate in external BI.
Key Points
- Single org limit: ~1B records. 500M is halfway to limit.
- Archive strategy: move old records to Data Cloud or external warehouse.
- Multi-org: split by time. Each org queries independently.
- Data Cloud: unified query layer across multiple orgs.
"500M records: archive old data, split across orgs, use Data Cloud for unified queries, external BI for aggregation."
93
Sync Strategy for 100M Records (Salesforce + Data Warehouse)
Advanced
Direct Answer
Full sync (100M records) = millions of API calls, slow. Better: incremental sync (changed records daily, via CreatedDate/LastModifiedDate filter). Reduces daily load to 1-10% of total. Change Data Capture (CDC) for real-time delta.
"100M record sync: incremental only (CreatedDate > yesterday). CDC for real-time. Idempotency key for retries."
94
Querying 500M Records for Reporting: Avoid Timeout
Advanced
Direct Answer
Query 500M records = timeout. Solution: (1) Add required date filter (THIS_QUARTER = 50M not 500M). (2) Data Cloud (pre-aggregated). (3) Batch jobs overnight (store in summary object). (4) External BI (Tableau, warehouse).
"500M record query: add date filter, use Data Cloud for aggregates, batch overnight, external BI for analytics."
95
Lock Contention in Bulk Operations
Advanced
Direct Answer
UNABLE_TO_LOCK error = record locked by another transaction. Solution: reduce batch size, stagger updates, use serialized Queueable, schedule during low-traffic hours.
"Lock contention: reduce batch size, serialize via Queueable, schedule low-traffic hours. UNABLE_TO_LOCK usually resolves on retry."
96
Cost Optimization: Reduce API Calls on 100M System
Medium
Direct Answer
Batch API calls (100 records/call = 100x reduction), incremental sync (90%), caching, archive. Target: 1000x cost reduction.
"Reduce API costs: batch calls, incremental sync, caching, archive. Target 1000x cost reduction."
97
Scaling OAuth: Authenticate 1M Concurrent Users
Advanced
Direct Answer
Salesforce OAuth = 100 tokens/sec limit. 1M users exceeds capacity. Solution: token caching, session timeout, load balance via external provider (Okta, Auth0).
"1M users: cache OAuth tokens, session timeout, load balance via external provider for mega-scale."
98
Real-Time Analytics on 500M Records
Advanced
Direct Answer
Real-time + 500M = need external analytics. Architecture: Salesforce (transactional), Data Cloud (unified layer ~15min refresh), Tableau (dashboards ~5min cache). Sub-second = external OLAP (Redis, ClickHouse).
"Real-time analytics on 500M: Data Cloud ~15min refresh, Tableau ~5min cache. Sub-second = external OLAP."
Performance Optimization & Limits
7 Questions99
10 Triggers on Same Object: How to Coordinate?
Advanced
Direct Answer
10 triggers = chaos. Solution: single handler pattern. One master trigger delegates to handler classes (TriggerHandlerFactory controls order). Extensible, testable, predictable.
"10 triggers = chaos. Single handler pattern: one trigger delegates to handlers. Factory controls order. Extensible, testable."
100
SOQL Query: 50ms Locally, 5s in Production. Why?
Advanced
Direct Answer
Sandbox: 1k records. Production: 10M. Query time scales linearly with data. 100x data = 100x slower. Solution: add date filter, create index, test with prod-scale data in sandbox.
"Query scales linearly with data. 100x data = 100x slower. Test with prod-scale data in sandbox."
101
Batch Size Tuning: 200 vs 2000 Records?
Medium
Direct Answer
Larger batch = fewer batches (faster) but higher gov limit risk. Smaller = safer. Optimal: 200-500 records. Test with prod data to find sweet spot.
"Batch size: 200 (safe, slow) vs 2000 (fast, risky). Optimal: 200-500. Test with prod data."
102
Governor Limit Early Warning: Monitor Before Hit
Medium
Direct Answer
Log Limits at each step. Alert at 80% (SOQL > 8000 out of 10k). Check before risky ops. Stop gracefully before hitting limit.
"Monitor Limits at each step. Alert at 80%. Check before risky ops. Stop gracefully before limit."
103
CPU Time Limit (10s): Stay Under It
Medium
Direct Answer
CPU time = code execution. Avoid: nested loops O(n²), repeated regex, JSON parse 1M times. Solution: reduce iterations (Set/Map), compile regex once, batch parse.
"CPU time: avoid nested loops, repeated regex, repeated JSON parse. Use Set/Map, compile regex once, batch parse."
104
SOQL vs. In-Memory Processing: When to Use Each?
Medium
Direct Answer
SOQL: filtering, aggregation (server-side). In-memory: complex logic, iteration, calculation (client-side). Trade-off: SOQL is fast (database optimized) but limited. In-memory is flexible but uses heap. For 1M+ records: SOQL mandatory (in-memory would exceed heap).
"SOQL for filtering/aggregation (fast, limited). In-memory for complex logic (flexible, heap-limited). 1M+ records = SOQL mandatory."
105
Your Production Incident Story: What's One Major Issue You've Fixed?
Advanced
Direct Answer
This is the final question. Use it to tell your real war story (Q85-Q91 were examples). Pick one production incident, walk through: (1) What broke? (2) Root cause? (3) How did you diagnose? (4) How did you fix? (5) What did you learn? (6) How did you prevent recurrence? Interviewers love real stories — they show resilience, debugging skills, and systems thinking.
Key Points
- Tell a real incident (not hypothetical).
- Show debugging workflow (how you diagnosed).
- Explain root cause clearly (technical + process).
- Describe fix + prevention (learned something).
- Demonstrate ownership (you fixed it, you prevented recurrence).
"Tell a real production incident: what broke, root cause, diagnosis, fix, learning, prevention. Show resilience, debugging, systems thinking. Interviewers love real stories."
☕ Enjoyed this article?
SF Interview Pro is 100% free and maintained by a Salesforce professional. No ads, no paywalls, and no signup required. If this guide helped you prepare for an interview, earn a certification, or grow your Salesforce career, consider buying me a coffee! ☕💜
🇮🇳 UPI (India)
Pay by QR
GPay · PhonePe · Paytm · BHIM
New interview questions every week
Follow for fresh Salesforce Q&A, free courses, and real interview experiences — straight from the trenches.
Follow Us ↗