Rate Limiter Sliding Window With Per-Entity Limits

You are given a stream of requests in chronological order. Each request has a timestamp, a user id, and an experience id.
A request is accepted only when both of these limits still have capacity:
the number of accepted requests for the same user inside the active sliding window
the number of accepted requests for the same experience inside the active sliding window
Only accepted requests count toward future capacity. Denied requests are not stored. For a request at timestamp t, the active window is (t - windowLength, t], so accepted requests at timestamps less than or equal to t - windowLength are expired before checking the new request.
Return an integer array where 1 means the corresponding request is accepted and 0 means it is denied.

Function
rateLimiter(requestTimestamps: int[], userIds: int[], experienceIds: String[], windowLength: int, maxRequests: int) → int[]

Examples
Example 1
requestTimestamps = [1, 2, 3, 4, 5]
userIds = [1, 1, 2, 1, 2]
experienceIds = ["A", "A", "A", "A", "B"]
windowLength = 3
maxRequests = 1
return = [1, 0, 0, 1, 1]
The second request is denied because user 1 already has an accepted request in the window. The third request is denied because experience A already has an accepted request in the window. At timestamp 4, the timestamp 1 request has expired, so user 1 and experience A both have capacity.
Example 2
requestTimestamps = [10, 11]
userIds = [1, 2]
experienceIds = ["game-1", "game-1"]
windowLength = 10
maxRequests = 1
return = [1, 0]
The second user has no accepted request yet, but the shared experience has already reached its limit.
Example 3
requestTimestamps = [1, 2, 3, 4]
userIds = [7, 7, 7, 7]
experienceIds = ["A", "A", "A", "A"]
windowLength = 3
maxRequests = 2
return = [1, 1, 0, 1]
The denied request at timestamp 3 is not stored. Before timestamp 4 is checked, the accepted timestamp 1 request expires.

Constraints
requestTimestamps.length == userIds.length == experienceIds.length
requestTimestamps is sorted in nondecreasing order.
windowLength > 0
maxRequests > 0

Keep two hash maps. One maps user id to a deque of accepted timestamps, the other maps experience id to a deque. For each request at time t, pop from the front of both deques while the front is <= t - windowLength. Then check whether both deque sizes are below maxRequests. If so, push t onto both and output 1. Otherwise output 0 and store nothing. Sorted timestamps mean each deque stays sorted, so expiry is amortized O(1) and the whole thing runs in O(n). The classic pitfalls: using < instead of <= on expiry, so the boundary request lingers. Storing denied requests, which Example 3 explicitly tests. Only pushing into one map when both must update. Evict from both maps before checking either. If you freeze on the live OA, StealthCoder can surface this deque structure fast.

If you see this problem in your OA tomorrow, the play is to recognize the pattern in 30 seconds. StealthCoder buys you that recognition.