Q:

Why does the /events service sometimes pause for a couple of minutes?

In developing the firehose service, I found that the /events API often "pauses" for a couple of minutes before resuming. Is this a known issue?
Specifically, I am polling /events every 10 seconds using a custom filter with all fields turned on. I'm using the since parameter to ask for only events that are newer than the most recent one received so far. I'll always get at least one previously seen event back (and ignore it because I've already seen it). The numbers I'm getting every 10 seconds look something like (count of new events):
..., 8, 1, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 42, 4, 1, 3, ...
..., 2, 5, 7, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 38, 4, 4, 2, ...
It appears that the events that were not sent during the quiet period are all sent after the flow resumes.
I do recognise the backoff element but I'm not receiving any of those.

A:

The comments are more or  less correct; caching applies to the /events endpoint just like every other method.
This is by design for now.  We have looked at differing caching policies for /events and /inbox/* routes, as the minute lag on those methods is a bit heavy handed; though we still need to protect ourselves from abusive requests.

