Concurrent Token-Bucket Rate Limiter
Reported by candidates from Charta Health's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
Charta Health reportedly put a token-bucket rate limiter on its OA in September 2026, and it looks scarier than it is. The title says concurrent, but the same-timestamp calls just run in input order. It's a one-pass simulation with exact arithmetic. If you've got an invite in your inbox, the whole question is avoiding float bugs and overflow. StealthCoder sits invisibly on your screen as a safety net if you blank mid-assessment, but you can walk in knowing the plan already.
The problem
Simulate a token-bucket rate limiter. The bucket has integer capacity, starts full at timestamp 0, and refills continuously at refillPerSecond tokens per second. Process the acquire operations in input order. Operation i occurs at timestamps[i] milliseconds and requests requestedTokens[i] whole tokens. Before deciding that operation, refill the bucket through its timestamp and cap the available amount at capacity. If enough tokens are available, consume the entire request and return true; otherwise consume nothing and return false. Fractional tokens are retained exactly between operations and are never rounded. Operations with the same timestamp represent an atomic linearization of concurrent callers and are processed in input order. Return one Boolean result per operation. Function applyTokenBucket(capacity: int, refillPerSecond: int, timestamps: int[], requestedTokens: int[]) → boolean[] Examples Example 1 capacity = 3 refillPerSecond = 2 timestamps = [0,0,250,500,1000] requestedTokens = [3,1,1,1,2] return = [true,false,false,true,false] The first request empties the bucket. At 250 ms only half a token exists, while at 500 ms one full token exists. The final request sees only one token and is rejected. Example 2 capacity = 5 refillPerSecond = 1 timestamps = [0,2000,2000,7000] requestedTokens = [4,3,1,5] return = [true,true,false,true] After two seconds the bucket has exactly three tokens. The next same-time request is rejected without changing the balance, and the long idle period fills the bucket to capacity. Example 3 capacity = 1000000 refillPerSecond = 1000000 timestamps = [0,1000000000] requestedTokens = [1000000,1000000] return = [true,true] The first request empties the bucket. The second operation occurs after a long idle period, so the bucket is capped back at capacity. Wide integer arithmetic is required for the refill product. Constraints 1 <= timestamps.length == requestedTokens.length <= 5000. 1 <= capacity, refillPerSecond <= 10^6. 0 <= timestamps[i] <= 10^9, and timestamps are nondecreasing. 1 <= requestedTokens[i] <= capacity. Each listed operation is one atomic acquire decision in the given order.
Reported by candidates. Source: FastPrep
Pattern and pitfall
Brute force isn't even the issue. With at most 5000 operations, a single pass is trivial. The real constraint is precision: timestamps reach 10^9 ms and refill rate reaches 10^6, so elapsed times rate hits 10^15. That overflows 32-bit ints, so use 64-bit. Don't use floats, since fractional tokens must be retained exactly. Store the balance as milli-tokens: tokens * 1000. Each step adds (deltaMs * refillPerSecond) milli-tokens, capped at capacity * 1000. A request needs requested * 1000 milli-tokens available. Check, subtract on success, leave untouched on failure. Common pitfalls: dividing by 1000 and truncating, forgetting to cap before the decision, and consuming tokens on a rejected request. Update the last timestamp every operation, even rejected ones. If you freeze mid-OA, StealthCoder is the hedge that hands you this exact structure live.
StealthCoder is the hedge for the one pattern you didn't drill. It runs invisibly during the screen share.
You can drill Concurrent Token-Bucket Rate Limiter cold, or you can hedge it. StealthCoder runs invisibly during screen share and surfaces a working solution in under 2 seconds. The proctor sees the IDE. They don't see what's behind it. If you're reading this with an OA window open, you're who this was built for.
Get StealthCoderRelated leaked OAs
You've seen the question.
Make sure you actually pass Charta Health's OA.
Charta Health reuses patterns across OAs. If you're reading this with an OA window open, you're who this was built for. Works on HackerRank, CodeSignal, CoderPad, and Karat.
Concurrent Token-Bucket Rate Limiter FAQ
What's the trick in the Charta Health token bucket problem?+
Avoid floats. Track the balance in milli-tokens so refill is deltaMs * refillPerSecond, an exact integer. Cap at capacity * 1000, compare against requested * 1000, and subtract only on success. That removes every rounding concern in one move.
Do I need 64-bit integers?+
Yes. A gap of 10^9 ms times a refill rate of 10^6 gives 10^15, far beyond 32-bit range. Use long in Java or C++. Python handles it natively. You can also cap early, but 64-bit math is the simplest fix.
How should same-timestamp operations be handled?+
Process them in input order. The delta is zero, so no refill happens, and each request sees the balance left by the previous one. Example 2 shows this: the second same-time request fails because the first consumed the tokens.
How hard is this really?+
Easy to medium. There's no fancy data structure, just a loop with careful arithmetic. Most failures come from float rounding, overflow, or consuming tokens on a rejected request. Test your code against all three examples before submitting.
How do I prepare in 48 hours?+
Write the milli-token loop from scratch once, then run the three examples by hand. Add edge cases: request equal to capacity, a huge idle gap, and repeated timestamps. Twenty minutes is enough for a simulation like this.