@eikaramba/node-red-ratelimiter

A modified version of the official Node-RED delay node that implements true rate limiting with immediate message processing. Delay option is completely removed, use the original node for that.

Key Features

1. True Rate Limiting

Unlike the original delay node which queues messages and releases them at fixed intervals, this node:

• Processes messages immediately when they arrive (if within rate limit)
• Drops messages that exceed the rate limit instead of queuing them
• Resets the rate limit counter based on actual message arrival times

2. Flexible Rate Configuration

Supports various rate limiting scenarios:

• X messages per second/minute/hour/day
• Custom periods (e.g., 6 messages per 28 hours)
• Configurable through node settings or dynamic msg properties

3. Burst Mode (Optional)

New feature that allows accumulation of unused rate limit slots over time (see detailed examples below)

Use Cases

Standard Rate Limiting

Perfect for:

• Monitoring systems that need to limit alert frequency
• API integrations with rate limits
• Event throttling where immediate processing is important

Example (1 message per day):

1Hour 0: Message A → Sent
2Hour 2: Message B → Dropped (within 24h limit)
3Hour 25: Message C → Sent (new period)
4Hour 79: Message D → Sent (new period)

New: Allow Burst Option

Example 1: 3 messages per hour

Allow Burst: Disabled

1Time 0:00 - Message A → Sent (1/3)
2Time 0:10 - Message B → Sent (2/3)
3Time 0:20 - Message C → Sent (3/3)
4Time 0:30 - Message D → Dropped (limit reached)
5Time 1:05 - Message E → Sent (1/3) (new hour started)
6Time 1:06 - Message F → Sent (2/3)
7Time 1:07 - Message G → Sent (3/3)
8Time 1:08 - Message H → Dropped (limit reached)

Allow Burst: Enabled

1Time 0:00 - Message A → Sent (1/3)
2Time 0:10 - Message B → Sent (2/3)
3Time 0:20 - Message C → Sent (3/3)
4Time 0:30 - Message D → Dropped (limit reached)
5// No messages for 2 hours
6Time 3:00 - Message E → Sent (1/9) (3 hours worth of tokens accumulated)
7Time 3:01 - Message F → Sent (2/9)
8Time 3:02 - Message G → Sent (3/9)
9Time 3:03 - Message H → Sent (4/9)
10Time 3:04 - Message I → Sent (5/9)
11Time 3:05 - Message J → Sent (6/9)
12Time 3:06 - Message K → Sent (7/9)
13Time 3:07 - Message L → Sent (8/9)
14Time 3:08 - Message M → Sent (9/9)
15Time 3:09 - Message N → Dropped (limit reached)

Example 2: 1 message per day

Allow Burst: Disabled

1Day 1 10:00 - Message A → Sent
2Day 1 14:00 - Message B → Dropped
3Day 2 08:00 - Message C → Sent
4Day 2 20:00 - Message D → Dropped
5Day 3 15:00 - Message E → Sent

Allow Burst: Enabled

1Day 1 10:00 - Message A → Sent
2Day 1 14:00 - Message B → Dropped
3// No messages for 3 days
4Day 5 08:00 - Message C → Sent (1/4) (4 days worth of tokens accumulated)
5Day 5 08:01 - Message D → Sent (2/4)
6Day 5 08:02 - Message E → Sent (3/4)
7Day 5 08:03 - Message F → Sent (4/4)
8Day 5 08:04 - Message G → Dropped

Example 3: 6 messages per 28 hours

Allow Burst: Disabled

1Hour 0:00 - Message A → Sent (1/6)
2Hour 0:30 - Message B → Sent (2/6)
3Hour 1:00 - Message C → Sent (3/6)
4Hour 2:00 - Message D → Sent (4/6)
5Hour 3:00 - Message E → Sent (5/6)
6Hour 4:00 - Message F → Sent (6/6)
7Hour 5:00 - Message G → Dropped
8Hour 28:00 - Message H → Sent (1/6) (new period started)
9Hour 28:30 - Message I → Sent (2/6)

Allow Burst: Enabled

1Hour 0:00 - Message A → Sent (1/6)
2Hour 0:30 - Message B → Sent (2/6)
3Hour 1:00 - Message C → Sent (3/6)
4// No messages for 56 hours (2 periods)
5Hour 57:00 - Message D → Sent (1/18) (3 periods worth of tokens)
6Hour 57:01 - Message E → Sent (2/18)
7Hour 57:02 - Message F → Sent (3/18)
8// Can send up to 15 more messages immediately

Key Differences:

1. Without Allow Burst:

   • Tokens reset at the start of each period
   • Maximum tokens = rate limit
   • Unused tokens are lost
   • More predictable, steady flow

2. With Allow Burst:

   • Unused tokens accumulate over time
   • Maximum tokens = rate limit × elapsed periods
   • Allows "catching up" after quiet periods
   • More flexible, but can cause traffic spikes

Use Cases:

1. Allow Burst Enabled:

   • Batch processing systems that need to catch up after downtime
   • Systems where occasional bursts of messages are acceptable
   • Backup or replication systems that need to sync after disconnections

2. Allow Burst Disabled:

   • Systems requiring strict, consistent rate limiting
   • Real-time processing where even distribution is important
   • APIs with strict rate quotas
   • Systems sensitive to traffic spikes