Cédric Soulas
Motion graphics about programming


Episode 13 - Two rate limiting strategies Monday, 11 Dec.

Last Monday I introduced the following issue:

If your stream is created from key presses or mouse movements, you’ll likely deal with bursts of events. But you can’t react to every single event, as it would overload the CPU or flood the servers with too many requests.

I presented the ❚ debounceTime card. It rate-limits events, based on an “emission silence” window of time. Learn more about it in Episode 12.

Today, we explore another rate-limiting strategy with the ❚ throttleTime card. Like ❚ debounceTime, it accepts a time period argument. But ❚ throttleTime doesn’t delay events:

Use a ▬ number piece on ❚ throttleTime to set a time period, such as 500 milliseconds. Then, this is how ❚ throttleTime operates:


❚ debounceTime and ❚ throttleTime both accept a time period and rate limit the emissions of the input stream. But as you can see on the visualization above, they operate in a very different way. Take some time considering both options for your next project!

Cards to learn Reactive Programming

Focus on one new concept – every Monday

Occasional updates, plus:
Cédric Soulas
Motion graphics about programming