Before going deep to the idea, understanding of the jargon is required.
Jitter time is kind of random delay time between request is created and is arrived to the other resources.
Suppose there are two resources interacting from A to B, hundreds or thousands of requests is hitting resource B. Without adding a jitter time, potentially it could hit 100+ request per second (RPS). There's no real number collected but conceptually adding a jitter time would reduce the RPS hitting the resource.
For example, jitter time of 1 minute was added to resource A when calling B. So the request coming from A will be randomized up to 1 minute time, first request can run in the 7th second, another can run on 59th second, another can run on the 32nd second, and so on.
There will always a potential that a request can have the same jitter time, but at least it reduces the potential of all of the requests running at the same time.
Things to consider
Not all of the use cases is fit implemented a jitter time.
- Time sensitive action might not be able to be implemented this method.
Example
- For a scheduled action or a cron job for example, this will be great place to implement jitter time. So, once the job is executed and bring a lot of request, it will be jittered.
Cron job usually will took some data from database then being run simultaneously.
Example invoice invalidation
- Cronjob run
- get expired invoices, suppose there are 1000 invoices.
- invalidate 1000 invoice. <- before going to this resource, jitter time can be added, so invalidate invoice won't be too heavy.
Comment below what other use case or solution can be done and how does it help you?
Connect on linkedin!
Top comments (0)