Original practice scenario inspired by Salesforce, Inc.'s public business context; this is not a reported interview question or a description of its internal systems. A fictional multi-tenant CRM service processes background imports. One tenant submits thousands of jobs and delays small imports for everyone else. Describe a fair queue implementation and tests without claiming any particular vendor architecture.
Read model answer +
Separate per-tenant admission from global worker capacity. A single FIFO queue lets a large tenant dominate waiting time even when every individual job is valid.
Work through it
Maintain bounded tenant queues and choose a scheduling policy such as round-robin or weighted deficit scheduling. Define concurrency and cost limits at the tenant level.
Make job execution idempotent and preserve retry attempt state. A failed job should not bypass fairness by repeatedly returning to the front of a global queue.
Test a noisy tenant, many small tenants, a long-running job, repeated failures, and worker restarts. Measure per-tenant wait time and completion fairness alongside total throughput.
Tradeoffs to discuss
Strict fairness can reduce throughput when job costs differ. Estimated-cost scheduling helps but must tolerate inaccurate estimates and avoid starving expensive legitimate work.
Common pitfalls
Limiting submission rate alone does not control queued backlog.
A global average latency hides a tenant that is consistently starved.
Original practice scenario inspired by Salesforce, Inc.'s public business context; this is not a reported interview question or a description of its internal systems. A synthetic CRM search service caches permission-filtered results. An administrator revokes a user's access while cached results and search indexes still contain the record. Design a read path that handles revocation responsibly.
Read model answer +
Treat authorization as a current read decision, not merely an indexing-time filter. Cached discovery results may improve speed, but they cannot be the sole authority after permissions change.
Work through it
Include tenant and user authorization context in cache keys and isolate tenants throughout indexing and retrieval. Version permission state and publish revocation events reliably.
Recheck access against an authoritative or sufficiently fresh authorization layer before returning sensitive record content. Invalidate affected caches and indexes asynchronously as a secondary measure.
Test revocation during an in-flight search, stale caches, group membership changes, and unavailable authorization services. Define a fail-closed behavior for sensitive reads.
Tradeoffs to discuss
Per-read checks add latency and load. Bounded permission caches need explicit freshness guarantees and stronger handling for revocations than ordinary content updates.
Common pitfalls
Removing a result from the next index build leaves a leakage window.
A cache key lacking tenant identity risks cross-tenant disclosure even without stale permissions.
