Salesforce System Design Interview Questions

Multi-tenancy can be implemented with shared schema + tenant ID for efficiency or separate schemas for stricter isolation. Use tenant-aware query filters to ensure no cross-tenant leaks. All customizations (fields, objects, workflows) should be stored in metadata so upgrades are non-breaking. Apply per-tenant rate limits, and isolate compute to prevent “noisy neighbor” performance issues.

The gateway should handle authentication, routing, and throttling. Use OAuth2 for secure integrations, rate limiting based on client tier, and request transformation to bridge different API versions. Add monitoring hooks for request/response metrics, and implement a caching layer for repeated queries. Make the gateway horizontally scalable and deploy across regions to support global customers.

Ingest CRM events (record creation, field changes) via event streams into a message bus like Kafka. Process them in real time using Flink/Spark Structured Streaming to compute KPIs like lead conversion rate or pipeline velocity. Serve results in a low-latency store (e.g., Redis, Druid) for dashboards. Enforce per-tenant data partitioning so customers see only their metrics.

Model workflows as event-condition-action rules. Trigger them from record events (e.g., “Opportunity Stage Changed”), evaluate conditions in a rules engine, and execute actions like sending an email or updating a field. Store workflow definitions in a metadata repository so they can be customized per tenant. Support branching logic, retries, and integration with external APIs.

Use an event-driven design where any system change (e.g., “New Lead Assigned”) emits an event to a notification service. Maintain user preferences for channels (email, SMS, in-app) and delivery times. Queue and batch notifications when appropriate to reduce noise. Use web push for instant in-app alerts and ensure multi-device sync so a dismissed notification disappears everywhere.

Store documents in encrypted object storage, with keys managed by a KMS. Link documents to records using metadata in the CRM database. Enforce access control via record-level permissions, and log every document access for audit purposes. Include versioning so older documents can be retrieved, and support secure external sharing with expiring signed URLs.

Use change data capture (CDC) to stream Salesforce updates to integration endpoints. Maintain a mapping layer to transform schemas between systems. Handle bidirectional sync with conflict resolution rules. Use incremental syncs for efficiency, and provide replay/recovery capabilities in case of failures.

Dashboards should pull from multiple datasets (CRM objects, analytics) and allow drag-and-drop widget customization. Store layout configs in metadata. Use pre-aggregated metrics in a cache for performance, and fetch live data for drill-downs. Apply tenant-based access control so each user sees only data they’re entitled to.

Aggregate logs from all services into a central system (e.g., Elasticsearch, Splunk) with tenant tags for filtering. Monitor metrics like API call volume, response time, and error rates per tenant. Set up alerts for anomalies. Retain logs per compliance rules, and provide tenants with self-service access to their own logs.

Treat each app as a metadata package containing components, configurations, and dependencies. The deployment service validates compatibility with the target org’s version and customizations. Install in a sandbox first, then promote to production. Support rollback if errors occur, and log all deployment actions for compliance.

Extend the CRM schema with custom objects whose structure is defined in metadata. Store definitions separately from instance data so the system can adapt dynamically. Index frequently queried fields, and support relationships to standard objects. Enforce record-level security for all custom objects.

Use asynchronous replication for non-critical data and synchronous replication for high-value, transactional records. Implement region-aware routing so users query the nearest replica. Provide eventual consistency guarantees, and monitor replication lag. Support failover in case of regional outages.

A scheduler service should manage cron-like triggers and ad-hoc jobs. Distribute jobs across worker nodes based on load and tenant priority. Ensure idempotency and retry logic for failed jobs. Maintain an execution log for audits, and allow tenants to configure schedules via a UI.

This involves real-time inventory management for seats, high-throughput reservation locking, and secure payments. Use an in-memory store like Redis for seat locks with TTLs, and a relational DB for confirmed bookings. Queue payment processing, and handle oversell prevention via optimistic locking. Scale the front-end to handle massive traffic spikes during popular events.