Write a simple in-memory fixed-window rate limiter for interview purposes.

• Blank keys are rejected.
• Each key has an independent counter.
• When now reaches the window end, start a new window.
• This is an interview in-memory version, not a distributed production limiter.

I would store one counter per key: window start and count. On each call, I validate the key, look up the counter, reset it if the window expired, then increment if the count is below the limit. I would use a lock for this simple in-memory version so two concurrent requests do not corrupt counts. I would also say that production usually needs a distributed counter such as Redis when multiple app instances exist.

public sealed class FixedWindowRateLimiter
{
    private readonly int _permitLimit;
    private readonly TimeSpan _window;
    private readonly object _gate = new();
    private readonly Dictionary<string, Counter> _counters = new(StringComparer.Ordinal);

    public FixedWindowRateLimiter(int permitLimit, TimeSpan window)
    {
        if (permitLimit <= 0) throw new ArgumentOutOfRangeException(nameof(permitLimit));
        if (window <= TimeSpan.Zero) throw new ArgumentOutOfRangeException(nameof(window));

        _permitLimit = permitLimit;
        _window = window;
    }

    public bool Allow(string key, DateTimeOffset now)
    {
        if (string.IsNullOrWhiteSpace(key))
        {
            return false;
        }

        lock (_gate)
        {
            if (!_counters.TryGetValue(key, out var counter) ||
                now - counter.WindowStart >= _window)
            {
                counter = new Counter(now, 0);
            }

            if (counter.Count >= _permitLimit)
            {
                _counters[key] = counter;
                return false;
            }

            _counters[key] = counter with { Count = counter.Count + 1 };
            return true;
        }
    }

    private sealed record Counter(DateTimeOffset WindowStart, int Count);
}

Each call is O(1) average time and O(k) space for k keys. Without cleanup, space grows with the number of distinct keys seen.

• Blank key.
• First request for a key.
• Request exactly at the window boundary.
• Multiple independent keys.
• Many unique keys causing memory growth.

• Use a fake clock by passing now explicitly.
• Call just before and exactly at the boundary.
• Use two keys interleaved to verify independent counters.

• Using local variables only and losing counters between calls.
• No thread-safety discussion.
• Not having any cleanup story for many old keys.
• Claiming this in-memory version works across multiple servers.