Forem: Roman Voloboev

Biased: Fixed Window rate limiting algorithm explained

Roman Voloboev — Sun, 05 Apr 2026 15:46:14 +0000

Fixed Window rate limiting algorithm enforces a limit on the number of events allowed within a time window. "Maximum 5 password attempts in 10 minutes" is a classic rate limiting example.

The common misconception about Fixed Window is that people describe it as "allows N requests per fixed calendar window" and then warn about the "burst at boundary" problem.

In rate-limiter-flexible Node.js package, a Flexible Fixed Window Algorithm is implemented. To be honest, I shouldn't call it "flexible," but I don't have much choice. Somehow the developer community has managed to portray the fixed window algorithm as if it were anchored to specific calendar time, as if it starts at 12:00 PM and ends at 12:10 PM. Not necessarily. For every unique client, IP address, or fingerprint, the window start time varies. It begins when the first request arrives, and the counter expires after a specified duration, e.g. 10 minutes. The window start is always variable.

Many articles describe the Fixed Window Algorithm incorrectly. That's why I deliberately call it "flexible."

The false belief that gets copied over and over, from one article to another: it leads to bursts at the boundary of windows. Let's take a closer look.

If every unique client has its own window start time, then boundaries don't matter. In many services you expect traffic spikes allowed. Here's the deeper explanation:

When you use rate-limited services, like AI agents, do you care if you spend your daily allowed tokens at the end of the day and then continue working after midnight, consuming tokens from the next day? Of course you do. It's natural to expect that once a limiter resets, tokens become available. Nobody calls this a boundary problem. On the contrary, you'd be frustrated if that spike on the window boundary weren't allowed.
Creating a boundary spike is less probable statistically than it seems. To pull it off, a client would have to try 1 password, wait 9 minutes and 59 seconds, try another 4, and then immediately try 5 more. The probability of that event is quite low. That's the magic of a flexible window start.
Statistically, different clients send requests at different times. They are not in perfect sync. Even if one client manages to create a spike on a window boundary, it isn't an issue: other clients follow different patterns, causing overall requests to scatter across time.
Sure, a malicious user could control 100 accounts and coordinate attacks on boundaries. But does Token Bucket protect against that? No. The same attacker can simply wait for the bucket to refill and then unleash a burst. Speaking of bursts, before Token Bucket was introduced in the 1980s, Leaky Bucket was the primary pattern for limiting traffic. Its problem was that it didn't allow traffic bursts at all. Token Bucket does. And that's never mentioned as an issue. It's a feature.
There is one case you should be careful of. If you're limiting requests because of infrastructure constraints and traffic spikes could degrade performance, create two limiters: one for unique clients and one for total traffic per second. This approach keeps your application running under pressure, with some users' experience degraded rather than everyone's. You don't have many options here. You either make the user experience worse by disallowing traffic spikes entirely, or you mitigate the consequences of allowing them. No rate limiting algorithm can win the fight between your infrastructure limitations — limited budget, in fact — and an overwhelming volume of malicious requests. To manage spikes even more effectively, take a look at BurstyRateLimiter. It allows spontaneous traffic bursts with finer control.

After years of studying and applying different rate limiting algorithms, I've found that any algorithm can be adapted for specific needs. What I value about the Flexible Fixed Window Algorithm is that it provides clear control over application behavior and the ability to build custom solutions across multiple dimensions of traffic using two or more combined limiters. And it is always predictable in terms of performance.

Never forget to question the basics. Take control over the information you consume.
Happy coding!

Perspective: bridging digital and physical realms with atomic counters

Roman Voloboev — Wed, 29 Oct 2025 09:58:49 +0000

Numbers

Numbers have no physical existence. They are abstract. Humanity created numbers to manage the present. It was the first step towards virtuality. We needed to count animals in the herd, days, harvest, and people in the tribe. In time we realized that with numbers we can predict the future.

By observing the motion of the planets, astronomers have calculated their orbits and can accurately predict eclipses centuries in advance. Meteorologists analyze temperature, pressure, humidity and predict the weather. Insurance companies calculate accident risks, doctors evaluate the effectiveness of treatments, and economists forecast market growth. The more data, the more accurate the forecast. But everything starts from measuring and counting.

Counting in everyday life

You wake up in the morning an hour before work starts. One hour is enough to have a calm morning routine, fry eggs and have breakfast. You go to the bathroom, squeeze toothpaste onto your brush. While you are cleaning your teeth roughly estimate how much toothpaste is left - not much. After the bathroom you go to the kitchen. You open notes on your smartphone on the way and add the twentieth item to the shopping list. The list is getting full. More importantly, there are only six eggs left in the fridge - enough for three breakfasts. You plan to go online shopping this evening. Today is Thursday and goods will be delivered on Saturday, in two days. Perfect timing.

I've just described five minutes of human life. It required measuring and counting six different things. And there were no issues. We are very good at counting. Numbers help us to manage everyday life, make it more predictable and comfortable. The same as it was thousands of years ago.

Problems begin in the evening when we go to shop online.

Counting online

The computer era and then the global network created a need to operate with very big numbers. Numbers still serve us and still make our life more predictable and comfortable, but we don't know them anymore. Computers do calculations for us. We are not able to count at the speed of billions of operations per second. It is beyond our natural abilities. We can't even imagine that process. It is too fast.

We've moved many everyday activities to online web services, messengers, online shops, and video calls. We get payments in pure numbers that arrive as another record in some database and are displayed in a mobile banking app. We pay numbers online to buy things. In other words, we partly live in virtuality.

The impression that the global network is huge is not wrong. It is huge. However, one online shop may be served by one real server in a data center. It is a relatively small box, smaller than a single shelf in an offline supermarket. In this box there are virtual parts of us, our motives and activities, and data from thousands of customers. Small box full of microchips and advanced electrical components. No eggs inside.

In the physical world, there is no way thousands of customers could go near a single shelf. In virtuality, customers are put inside the sophisticated machine. It is a highly concurrent space. Activities of thousands of customers are handled inside. And this is a problem because at the end of the day we eat not numbers but eggs. Every number should represent a real pack of eggs waiting for a customer somewhere in a warehouse. A number can be copied in the computer memory, but the last pack of eggs can't be copied in a warehouse. Only one customer must be able to get the last pack.

When we go to an offline shop to buy eggs the process is straightforward. There are other customers in the supermarket. They also buy eggs. If you take the last pack of eggs from the shelf and put it in your basket, nobody else will be able to take it from the shelf anymore. The laws of reality naturally handle it.

Things change online. When thousands of customers shop online there is a big chance that two or three customers could take the same last pack of eggs. Poorly designed virtual shelves allow that mistake. Obviously, in the end only one customer would get the pack of eggs. Others would be frustrated by not receiving eggs during the next delivery.

This is an example of when counting must be implemented correctly to avoid race conditions. We need a bridge between virtuality and reality.

Adapter for virtuality

Virtuality is a model of reality. Virtuality consists of a huge amount of numbers. We change numbers, and laws of the model change. In virtuality, we can create as many eggs as we want and store them as a very-very big number that could be larger than the amount of atoms in the observable universe.

Our virtuality is very convenient because it is fast, flexible and accessible just with a mobile app or browser. The problem begins when virtuality should be connected back to reality. We can't eat numbers, can we? We eat eggs that are limited in the real world.

This is where we should create a way to connect two worlds. Connect the concurrent and incredibly fast digital realm to limited reality. The solution lies in making our virtual counters work like reality does - one item, one customer, one transaction. We need a proper adapter. Let's start from a broken one.

Non-atomic counters

The number of egg packs in a warehouse is stored in computer memory. When two customers want to put the last pack of eggs in their basket, the computer should verify if the number is not zero, if there is at least one pack of eggs in a warehouse. Online shops can't sell eggs that don't physically exist.

How to verify eggs exist? Retrieve a number of packs from computer memory, subtract number one that represents a pack of eggs, and set the result back to computer memory. Easy, right? Not quite. Note that there is a time gap between getting a number and setting the changed number back. This is a potential issue.

There is a chance that another customer will get the same number from computer memory before the first customer's updated number is saved in computer memory. This causes race conditions. Both customers get a pack of virtual eggs represented as numbers, but in the real warehouse there is just one last pack. Unfortunately, one customer will not get eggs. Not a happy end.

Atomic counters

There is a simple fix that keeps all customers happy. While the first customer buys eggs, no other customers should be able to change the number in computer memory. The process should be non-divisible - atomic. In reality, one pack of eggs can't be placed in two different baskets at the same time. Virtuality should mirror this law.

When three customers simultaneously click the "Add to cart" button, the first customer should obtain an exclusive lock on the computer memory that stores the number of eggs, subtract one, set the changed value back to memory, and only after that release the lock. The other two customers must wait.

In essence, it creates a queue of customers waiting their turn to get exclusive access to the virtual shelf with eggs. This is how atomic counters properly bridge the gap between the digital and physical realms.

Token Bucket vs Bursty Rate Limiter

Roman Voloboev — Sun, 12 Apr 2020 12:54:59 +0000

This post is created under the impression that there is a wrong opinion on fixed window rate limiting approach.

As author of rate-limiter-flexible Node.js package I got some experience using different rate limiter approaches in different environments.

Extended version of this post with description of Token Bucket and Fixed Window rate limiting approach was originally posted on Medium. So if you want more details, read extended vesion.

Fixed Window rate limiter is slightly better than Token Bucket. Here is why. | by Roman Voloboev | Medium

Roman Voloboev ・ Mar 7, 2024 ・
Medium

TL;DR: Fixed Window rate limiter with traffic burst allowance can easily replace Token Bucket and even bring performance boost.

Main difference

Token Bucket allows traffic burst by nature. If tokens are not taken during some period of time, token bucket is refilled partly or completely. More tokens in a bucket, higher traffic burst allowed.

Bursty Rate Limiter like from rate-limiter-flexible package actually consists of two Fixed Window limiters: one for constant rate like 2 requests per second and another for traffic burst allowance like 3 requests per 5 seconds.

Visual traffic comparison

There are two examples on Chart 1 and Chart 2 below. Order and amount of requests are the same for both. Square without background color represents not touched token/point. Green square defines consumed token and allowed action. Red square — rejected action.

Chart 1: Token Bucket with capacity 5 and fill rate 2 tokens per second.

Chart 2: BurstyRateLimiter with 2 points per second and burst allowance 3 requests per 5 seconds.

You could notice, allowed requests’ shape is not the same, but quite similar. Both allowed traffic bursts.
You could also notice, that BurstyRateLimiter allowed 5 actions in time window 5–6, but Token Bucket allowed 2 only. Token Bucket didn’t have enough tokens by that time. But it could have, if there are no requests for time window 4–5.

Benchmarks

Two Node.js packages are benchmarked: hyacinth’s TokenBucket and rate-limiter-flexible’s BurstyRateLimiter.

The aim of this benchmark is comparison of two algorithms not providing absolute truth on every of them. Results may be different on different environments.

Chart 3: 1000 requests per second from 1000 concurrent clients during 30 seconds.

Chart 4: 2000 requests per second from 1000 concurrent clients during 30 seconds.

Note, Bursty Rate Limiter from rate-limiter-flexible applies inmemoryBlockOnConsumed option. It stores blocked users in process memory until their time window’s end. It speeds up processing requests. This is not only performance boost, but also good protection against massive DDoS attacks, if your application doesn’t have one yet.

Bursty Rate Limiter can be slower, since it requires to make 2 requests to a store in particular conditions. It all depends on amount of unique users, project and environment. But it is still fast enough.

Conclusion

Bursty Rate Limiter’s advantages:

It is more flexible in terms of central store. Fixed rate limiter implementation is relatively similar on different stores. Packages like rate-limiter-flexible or express-rate-limit provide ability to choose from several stores. It simplifies changes in your application.
It sets exact amount of traffic burst allowance. No surprises.
It is easier to cache known time window end to avoid extra requests to store. Not really big advantage for all applications, but still could be useful for some.

Bursty Rate Limiter’s disadvantages:

It can be slower on high traffic like 5000 requests per second and more, as it makes 2 requests to a store sometimes. Especially, if in-memory block technique is not applied.

You can test it yourself and compare using this gist.

Thanks for reading!

How to upgrade Node.js and dependencies. Results.

Roman Voloboev — Thu, 09 Jan 2020 12:47:39 +0000

This is a how-to article reflecting back on our upgrade process from Node.js 8 to Node.js 12 for the Snugg Pro web application. Described upgrade process is fair for any Node.js version.

TLDR: We upgraded from Node.js 8 to Node.js 12 and decreased the average response time of Snugg Pro (a web application) by 40%.

Node.js version 8's end-of-life was at the end of 2019. This was (and still is) a good moment to migrate to the latest version 12 LTS. Here at Snugg Pro we had prepared the migration in the middle of November 2019. We had tested it on staging 3 weeks before upgrading our production servers.

How-to

Check your dependencies

There is a lot to upgrade in a mature javascript application. You should be smart about what is going to be upgraded and what is not.

Remove unused dependencies

First of all, remove all unused dependencies. You can use a package like depcheck or you could do it manually.

Update dependencies for your Node.js version

If you are going to upgrade packages incompatible with a new Node.js version only, it is ideal case.

In package.json, Change node version in engines sections. It will stop installation with wrong Node.js version.
Update Node.js version any appropriate way. I use nvm: nvm install 12.14.0 and nvm alias default 12.14.0. You can reinstall global packages with --reinstall-packages-from=<old-node-version>. Read more about nvm
Try to install dependencies.
Fix all errors step-by-step. Decide if you want to upgrade to the latest package version or not on your own. Usually, there are release notes, you get exact version the most suitable and not broken. It is fine to go on with not the freshest version. I upgraded babel to 6.26.0 instead of 7.7.0, because the latter has conflicts with other dependencies.

Update vulnerable dependencies

Use npm audit or yarn audit to find vulnerable packages. It is strongly recommended.

Update dependencies to the latest version

You may want to take this opportunity to upgrade some packages to the latest major version by the way. This may require some refactoring. For example, the joi package was moved to @hapi/joi. This required us to change all import statements for this package but was relatively straight forward. I removed the deprecated bcrypt-nodejs package in favor of the bcrypt package. It affects authorization and authentication. The stakes are higher with such an upgrade but security is critical, so it is worth the extra hassle.

Make some strategic choices

Sometimes, you may need to force an unnatural version of application dependencies. This should be done sparingly but it is useful if you want to patch a security issue. For such cases, you should use the resolutions sections of package.json helps. Read more about the resolutions feature for yarn or for npm.

Give it time

Once all the dependencies are ready, it is time to deploy your changes to staging. No matter how sure you are or how complete your tests coverage is, you should stage it and forget it for while. The more you can wait and test the Node.js version upgrade on staging, the better your chances of catching unexpected issues. We tested it for 3 weeks, and still missed a minor bug related to error logging in one of our queue workers.

Comparing the performance of Node.js 8 and Node.js 12

All charts are provided by Newrelic.
Let's start from weekly service level agreement (SLA) report.

Weekly SLA

The last two columns/weeks reflects changes after upgrade to Node.js 12. It is easy to see all metrics are significantly improved. Apdex reaches 0.95.

There will be more charts with metrics next.You may want to read more about Garbage Collection in Node.js here or extended version here.

GC (Garbage collector) pause time

Before:

After:

There are more spikes on Node.js 8 and some of them take up more than 2 seconds per minute. Node.js 12 takes more milliseconds per minute on average, but there is only one spike of more than 1 second per minute. Node 12 is more balanced by default.

GC pause frequency

Before:

After:

Node 12 makes 2 to 3 times more garbage collection pauses. The idea here is to continue to serve clients by making more frequent but much shorter pauses, instead of stopping everything for 1 second once.

Memory usage

You may already have a sense of the memory usage from above metrics. If Node.js 12 collects garbage more frequently by default, it uses noticeably less memory on average.

Before:

After:

Node.js 12 rarely consumes more than 220Mb, but Node.js 8 reaches 400Mb on peaks. Node.js 12 is smarter with memory by default.

Maximum CPU time per tick

If you don't know what is tick in Node.js, you may read about event loop and ticks here

With Node.js 8, we got pauses upwards of 30 seconds. This was partly due to setting max-old-space-size to 440Mb for the V8 engine. Node.js would stop serving clients if the old space size reached the preset value. You can read about old space garbage collection here.

Conclusion

Node.js 12 V8 engine settings are balanced better by default. In addition, Node.js 12 brings a fresh version of the V8 engine, and it results in big performance improvements. You can read V8 engine release notes here for more details.

Moreover, Node 12 makes it easier to eliminate babel on the server, since Node.js 12 supports a lot of ES2016/ES2017/ES2018/ES2019 features out of the box.

At the risk of stating the obvious, upgrading to Node 12 will also ensure that you have access to all the features and security updates that come from running the latest LTS version of Node.js.

This concludes our run through of the Node 8 to Node 12 upgrade.

Thank you for reading.
Bye, folks.

PS: Many thanks to Benjamin Mailian – Snugg Pro Co-Founder / Head of Product for help with this article.

Non-atomic increments in NodeJS or how I found a vulnerability in express-brute package.

Roman Voloboev — Thu, 18 Apr 2019 07:05:50 +0000

TLDR: Use ExpressBruteFlexible to migrate from vulnerable express-brute package.

My aim is to provide unified package rate-limiter-flexible to manage expiring increments with flexible options and API, so any task related to counting events with expiration can be done with one tool.

I was looking for useful features across github several months ago. There are some good packages with similar purpose, I went trough their features and issues. Sometimes opened and even closed issues contain interesting ideas. express-brute has several opened issues.

Check twice. And then once again.

Warning orange light with the distinctive sound had switched on, when I read a ticket title global bruteforce count is not updating on more than 1000 concurrent requests.

Once all the 1000 requests are completed, the count in the express brute store doesn’t gets increased to more than 150 ever.

I checked number of downloads of express-brute on npm. Number was not small: more than 20k downloads per week. The issue was created more than 2 years ago. "Ok, I trust those users", - I thought and closed a browser's tab. I opened that ticket again in several days and decided to test it on my own.

Increment atomically. Especially in asynchronous environment.

I want you to understand more about express-brute package. It counts number of requests and then depending on options it allows to make request or prohibits during some number of seconds. The most important option is freeTries, it limits number of allowed requests. If developer sets 5, it should count 5 requests, then allow 6th and stop 7th, 8th, etc during some time window. It counts requests by user name or by user name and IP pair. This way it protects against brute-forcing passwords.

You should also know, that express-brute implements get/set approach to count events. It can store data in several famous databases. Here is the process:

Get counter data from a store on request.
Check some logic, check limits, compare expiration and current dates, etc.
Set new counter data depending on results from the second step.

You probably already get that. If our application processes 1000 concurrent requests, some requests are not going to be considered, because a Set operation overwrites previous Sets. It makes it clear, why somebody sees 150 instead of 1000 in a store! Slower database, more requests can be done invisibly. More threads or processes in an application, even more Set queries overwritten.

But that is not all. NodeJS event-loop makes it even more vulnerable. Let's see what happens with one NodeJS process:

Get query is sent to a store, but result is not received yet. I/O callback is queued on event-loop level. It may be in that queue more than one event-loop tick waiting a result from a store. There may be more requests to Get data from a store during that time. Those I/O callbacks are queued too.
Let's say, the first Get takes 10ms. Now our NodeJS process is ready to do math with results. But it also gets nine other Get results for requests made during 10ms time window. And all these Get results have the same value of counter ready to be incremented and Set.
Math made. It is brilliant. Counter is incremented. Set queries are sent to a store. The same value is set 10 times in a row. 1 counted instead of 10.

Interested in consequences?

Stop theory, give us real numbers.

First of all I reproduced it locally. But local tests are not amazing. They are not reflection of real asynchronous web world. "Ok, let's try something interesting and real", thought I. And discovered, that Ghost open-source project uses express-brute. I was excited to make experiments on their services. No harm, honestly.

The receipt is quite simple:

Load event-loop by some amount of requests. It should be slow to have long I/O queues. I launched a small tool to make 1000 requests per second.
Instantly try 1000 passwords.

I was using mobile internet from other continent and a laptop with eight CPU cores. I was able to make 14 password tries instead of 5. (Edit: I was actually able to make 216 tries instead of 5 later.) "Phew, it is nothing, Roman", - you may think. It allows to make about 5 more in 10 minutes. Then again 5 in 10 minutes, then 5 in 20 minutes, etc with default Ghost settings. About 60 tries per the first day from one laptop over mobile internet with a huge latency. 1000 computers would make 60000 password tries per day.

10 minutes is default minimum delay in Ghost project. Default minimum delay set by express-brute is 500 milliseconds and maximum delay 15 minutes with 2 free tries. I didn't test, but it would allow about 500 password tries per day from one computer. It is not safe! Especially, if this attack is a part of a bigger plan.

It is important not only for banks

Users tend to use the same password across several services. If you think your application is not interesting for hackers, you may be wrong. Hackers can use a weak security of one service for increasing probability of an attack to another service.

We do not have free time to fix it!

I made it possible to migrate in a couple of minutes. There is ExpressBruteFlexible middleware. It has the same logic, options and methods, but it works with atomic increments built on top of rate-limiter-flexible package.

It is simple to migrate.

If you have any questions or stories to tell, I'd glad to chat or listen about that!

Safer web: why does brute-force protection of login endpoints so important?

Roman Voloboev — Sat, 02 Feb 2019 12:20:26 +0000

We all know why. Because it saves private data and money. But that is not all. The most important, that it makes the internet safer place over all, so users can get better experience and be happier with web services.

Some time ago I've created a Node.js package rate-limiter-flexible, which provides tools against DoS and brute-force attacks with many features. I dived into this topic and discovered, that some javascript open-source projects don't care much about security. I am not sure about projects on other languages, but guess it is the same. There are many e-commerce projects, which don't care much too.

I've recently posted an article about brute-force protection with analysis and examples. You can read full version here.

Here is one example, first of all as a reminder, that we (developers, PMs, CEOs, etc) should take care of it. No time to write extra code? No worries, it is easy.

The main idea of protection is risk minimisation. Login endpoint limits number of allowed requests and block extra requests.
We should create 2 different limiters:

The first counts number of consecutive failed attempts and allows maximum 10 by Username+IP pair.
The second blocks IP for 1 day on 100 failed attempts per day.

const http = require('http');
const express = require('express');
const redis = require('redis');
const { RateLimiterRedis } = require('rate-limiter-flexible');
const redisClient = redis.createClient({
  enable_offline_queue: false,
});

const maxWrongAttemptsByIPperDay = 100;
const maxConsecutiveFailsByUsernameAndIP = 10;

const limiterSlowBruteByIP = new RateLimiterRedis({
  redis: redisClient,
  keyPrefix: 'login_fail_ip_per_day',
  points: maxWrongAttemptsByIPperDay,
  duration: 60 * 60 * 24,
  blockDuration: 60 * 60 * 24, // Block for 1 day, if 100 wrong attempts per day
});

const limiterConsecutiveFailsByUsernameAndIP = new RateLimiterRedis({
  redis: redisClient,
  keyPrefix: 'login_fail_consecutive_username_and_ip',
  points: maxConsecutiveFailsByUsernameAndIP,
  duration: 60 * 60 * 24 * 90, // Store number for 90 days since first fail
  blockDuration: 60 * 60 * 24 * 365 * 20, // Block for infinity after consecutive fails
});

const getUsernameIPkey = (username, ip) => `${username}_${ip}`;

async function loginRoute(req, res) {
  const ipAddr = req.connection.remoteAddress;
  const usernameIPkey = getUsernameIPkey(req.body.email, ipAddr);

  const [resUsernameAndIP, resSlowByIP] = await Promise.all([
    limiterConsecutiveFailsByUsernameAndIP.get(usernameIPkey),
    limiterSlowBruteByIP.get(ipAddr),
  ]);

  let retrySecs = 0;

  // Check if IP or Username + IP is already blocked
  if (resSlowByIP !== null && resSlowByIP.remainingPoints <= 0) {
    retrySecs = Math.round(resSlowByIP.msBeforeNext / 1000) || 1;
  } else if (resUsernameAndIP !== null && resUsernameAndIP.remainingPoints <= 0) {
    retrySecs = Math.round(resUsernameAndIP.msBeforeNext / 1000) || 1;
  }

  if (retrySecs > 0) {
    res.set('Retry-After', String(retrySecs));
    res.status(429).send('Too Many Requests');
  } else {
    const user = authorise(req.body.email, req.body.password);
    if (!user.isLoggedIn) {
      // Consume 1 point from limiters on wrong attempt and block if limits reached
      try {
        const promises = [limiterSlowBruteByIP.consume(ipAddr)];
        if (user.exists) {
          // Count failed attempts by Username + IP only for registered users
          promises.push(limiterConsecutiveFailsByUsernameAndIP.consume(usernameIPkey));
        }

        await promises;

        res.status(400).end('email or password is wrong');
      } catch (rlRejected) {
        if (rlRejected instanceof Error) {
          throw rlRejected;
        } else {
          res.set('Retry-After', String(Math.round(rlRejected.msBeforeNext / 1000)) || 1);
          res.status(429).send('Too Many Requests');
        }
      }
    }

    if (user.isLoggedIn) {
      if (resUsernameAndIP !== null && resUsernameAndIP.consumedPoints > 0) {
        // Reset on successful authorisation
        await limiterConsecutiveFailsByUsernameAndIP.delete(usernameIPkey);
      }

      res.end('authorized');
    }
  }
}

const app = express();

app.post('/login', async (req, res) => {
  try {
    await loginRoute(req, res);
  } catch (err) {
    res.status(500).end();
  }
});

Implementation of unblocking is up to you, there is suitable delete(key) method.

More examples in this article and in official docs

GraphQL - postponed technical debt or silver bullet?

Roman Voloboev — Fri, 01 Feb 2019 05:09:34 +0000

I've never worked with GraphQL long enough, but I get kind of feeling, it gives advantages on the first year of developing, but it takes much more than custom RESTful API later.

Curios, if somebody has statistic or observation on projects aged 3-5 years.
Are there any problems with refactoring?
Does code become too complex and takes much time to implement new features?

Forem: Roman Voloboev

Biased: Fixed Window rate limiting algorithm explained

Perspective: bridging digital and physical realms with atomic counters

Numbers

Counting in everyday life

Counting online

Adapter for virtuality

Non-atomic counters

Atomic counters

Token Bucket vs Bursty Rate Limiter

Fixed Window rate limiter is slightly better than Token Bucket. Here is why. | by Roman Voloboev | Medium

Roman Voloboev ・ Mar 7, 2024 ・ Medium

Main difference

Visual traffic comparison

Benchmarks

Conclusion

How to upgrade Node.js and dependencies. Results.

How-to

Check your dependencies

Remove unused dependencies

Update dependencies for your Node.js version

Update vulnerable dependencies

Update dependencies to the latest version

Make some strategic choices

Give it time

Comparing the performance of Node.js 8 and Node.js 12

Weekly SLA

GC (Garbage collector) pause time

GC pause frequency

Memory usage

Maximum CPU time per tick

Conclusion

Non-atomic increments in NodeJS or how I found a vulnerability in express-brute package.

Check twice. And then once again.

Increment atomically. Especially in asynchronous environment.

Stop theory, give us real numbers.

It is important not only for banks

We do not have free time to fix it!

Safer web: why does brute-force protection of login endpoints so important?

GraphQL - postponed technical debt or silver bullet?

Roman Voloboev ・ Mar 7, 2024 ・
Medium