This can be a complex issue. GNIP and Datasift provide data for a number of use caes, but one of the primary areas they serve is for tweets in non-display context or tweets in very limited (paywall, for example) contexts.
My recommendation: use the Search API for ad-hoc queries by your end-users. If they decide they want a query to be recurring, that they want to watch it from “now on” – add it to a queue you have for the next time you add additional terms to your outstanding streaming connection. Consider tiering access to your service to further allocate/direct resources.
A queuing system becomes pretty necessary when you’re working with the Streaming API. You want to limit reconnects as much as possible – one way to do that is to use two streams (different users) and use them alternately.
When you run into a situation where the basic limits are no longer adequate (not just because you want lots of breathing room
), send an email to api@twitter.com explaining in detail how you’re currently using the streaming API, information about who your users are and how they access your product, what they do with tweets within your product, and how heightened streaming limits will aid your ability to serve our mutual users. Often we’ll recommend you go to GNIP or DataSift, if it’s appropriate for your scenario.
It never hurts to make sure that tweets are fully actionable in your application: reply, retweet, favorite, follow; that your application meets display guidelines and so on.
Hope this helps you think about this. The Streaming API and OAuth API keys have very few relationships with each other when it comes to this stuff.