Simple Ratelimiter Feedback I'm preparing for coding interviews and I wanted to get feedback on this question which asks you to write a simple ratelimiter that can handle 5 requests every 2 seconds for example. Since it is for a coding interview setting, I don't think it needs to be perfect.
I looked at the guava Ratelimiter for inspiration for this.
Please let me know if I have made any errors or any improvements that can be made. Any feedback is appreciated.
public class RateLimit {
    private double maxCapacity;
    private double refillRate;
    private double availableTokens;
    private long lastRefill;

    public RateLimit(double maxCapacity, long windowInSeconds) {
        this.maxCapacity = maxCapacity;
        this.lastRefill = Instant.now().toEpochMilli();
        this.refillRate = TimeUnit.SECONDS.toMicros(windowInSeconds) / maxCapacity ;
        this.availableTokens = maxCapacity;
    }

    public boolean acquire() {
        return acquire(1, true);
    }

    public boolean acquire(double requiredPermits) {
        return acquire(requiredPermits, true);
    }

    public boolean tryConsume(double requiredPermits) {
        return acquire(requiredPermits, false);
    }

    private synchronized boolean acquire(double requiredToken, boolean shouldBlock) {
        refill();

        boolean acquired = false;
        if (availableTokens &gt;= requiredToken) {
            availableTokens -= requiredToken;
            acquired = true;
        } else if (shouldBlock) {
            double missingTokens = requiredToken - availableTokens;
            try {
                TimeUnit.MICROSECONDS.sleep((long) (refillRate * missingTokens));
                availableTokens = 0D;
                lastRefill = Instant.now().toEpochMilli();
                acquired = true;
            } catch (InterruptedException e) {
                System.out.println(&quot;Sleep interrupted&quot;);
            }
        }

        return acquired;
    }

    private void refill() {
        long now = Instant.now().toEpochMilli();
        if (now &gt; lastRefill) {
            long elapsedTime = now - lastRefill;
            double tokensToBeAdded = Math.floor(TimeUnit.MILLISECONDS.toMicros(elapsedTime) / refillRate);
            if (tokensToBeAdded &gt; 0) {
                availableTokens = Math.min(maxCapacity, availableTokens + tokensToBeAdded);
                lastRefill = now;
            }
        }
    }
```
Testability
Whilst not a prerequisite for a review, @Marc is correct that unit tests would be helpful here and you would usually want to include them in your exercise submission.  You want to demonstrate both that you know the code works as importantly that you've considered how easy it is to test.  Time in particular can be challenging to unit test if classes have not been constructed with it as a consideration.  You may wish to take a look at this Stack overflow question for some suggestions about how you could improve your time testability.
Naming
One of the things that struck me as a little odd was that your blocking methods are called acquire and your non-blocking method is called tryConsume.  I'm not sure I understand the disconnect, is there a reason it couldn't be called tryAcquire?  Have you been asked to provide both blocking and non-blocking versions of the limiter as part of the exercise?
final
Fields that don't change after they've been initialized (such as refillRate) should be marked as final to indicate that you're not planning on changing them.
Starvation and Flooding
Lets take your example of 5 requests every 2 seconds.  If I call acquire(500), nothing happens for 200 seconds, then 500 messages get sent (probably within a single second).  Is this the expected behaviour?  During the wait time while the number of required allocations are being waited on, no other threads are able to acquire and send either.  It's possible that this is expected/desired behaviour, however it seems like a potential flaw, particularly since a greedy blocking call could mean that the non-blocking request is never successful, so something I'd expect them to ask about if you get to interview.  Things to consider are do you need to allow a single call to reserve X permits, or would it be better to have them acquire single permits at a time as they send each message?  If you need to support multiple permits, should there be a limit on the maximum number of permits that can be requested in one go (such as the size of the window or maxCapacity).