Salesforce·Software Engineer·Onsite - System Design / Architecture·Senior

SeniorPrefer not to say

Apr 2026

Summary

System design round at Salesforce for a software engineer role, focused entirely on building a rate limiter for a high-cost API with user-configurable monthly quotas. Pretty deep dive, they wanted real tradeoffs not just buzzwords.

Questions Asked (1)

Design a rate limiter for an expensive API where each user can configure their own monthly quota. Walk through where the limiter lives, which algorithm you'd use and why, how you track and reset monthly usage, your storage choices, concurrency correctness, mid-month quota changes, failure behavior, and how you communicate limits back to clients.

System DesignTechnical Trade-offsAPI & Integrations

Author's notes

This is basically one big question with seven sub-questions inside it.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and scale, then propose a distributed rate limiter that sits in the API gateway or as a sidecar, using a sliding window or token bucket algorithm with Redis for atomic counters. Walk through data modeling for per-user monthly quotas, handling concurrency with Lua scripts or Redis transactions, and gracefully handling quota changes and failures.

Pro tip: Emphasize idempotency and atomicity: use Redis Lua scripts to ensure that checking and incrementing the counter happen atomically, preventing race conditions. Also, discuss how to handle quota resets without downtime by using a lazy reset or time-bucketed keys.

1. Clarify Requirements and Scale

Ask about expected QPS, number of users, quota granularity (monthly), and whether quotas are per API or global. Confirm if the limiter should be centralized or distributed.

2. Choose Placement and Algorithm

Decide where the limiter lives (API gateway, sidecar, or service mesh) and select an algorithm (e.g., sliding window counter or token bucket) that supports monthly quotas and is memory-efficient.

3. Design Storage and Data Model

Use a fast, atomic store like Redis to track usage per user per month. Model keys as `quota:{userId}:{year-month}` with a counter and TTL for automatic cleanup.

4. Ensure Concurrency and Correctness

Use Redis Lua scripts or transactions to atomically check and increment the counter. Handle race conditions and ensure that quota checks are consistent across distributed instances.

5. Handle Edge Cases and Communication

Address mid-month quota changes (update config and adjust counter), failure behavior (fail open or closed with fallback), and communicate limits via HTTP headers (e.g., X-RateLimit-Remaining) and 429 responses.

Key Points to Mention

Distributed rate limiting with Redis for atomic operations and low latency.
Sliding window or token bucket algorithm to smooth bursts and enforce monthly quotas.
Data model: per-user, per-month keys with TTL for automatic reset.
Concurrency control using Lua scripts or Redis transactions to avoid race conditions.
Mid-month quota changes: update configuration and adjust the counter or use a delta approach.
Failure modes: fail open vs. fail closed, and fallback mechanisms (e.g., local cache).
Client communication: HTTP 429 with Retry-After and rate limit headers.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.