Is there any order or precedence to how tweets are selected for rate
limiting when using the streaming api with many (hundreds to
thousands) of filter predicates.  I'm curious if rate limiting is
applied to the higher volume predicates in a filter, before it's
applied to lower volume ones.

We collect tweets for many users based on search terms supplied by
those users. With the search API, I could be sure that lower volume
searches always returned complete results. I might miss results on
extremely high volume searches, but most of the users would see no
effects of rate limiting. With the streaming api, we have to combine
all of the users' search terms into a single streaming filter. I'm
worried that if one or two of those predicates has a super high volume
which causes rate-limits, we could be missing tweets that match the
lower volume predicates.

Can one bad user supplied predicate spoil results for all of our other
users? I'm concerned because I'm seeing a lot of limit events coming
through and I can't tell which results we're missing. Is there a
better way for me to be approaching this problem?

Thanks!
Jason (@jmstriegel)

Reply via email to