So we have a few techniques for write throttling:-
http://stackoverflow.com/questions/24830079/firebase-rate-limiting-in-security-rules
Its not ideal but for read throttling a workaround could be
- client writes a "read access token" + server timestamp under a location keyed by their auth.uid
Security rules:
- enforce write throttling on the read access token writes
- read are predicated on the existence of a read access token within a reasonable timewindow for the reader
Its not normally an issue that come up, because reads are implemented using listen streams which are efficiently syncronized and kept up to date, its not usually an issue that a client "sends lots of read requests". The typical ways to get the server to resend the same data is to unsubscribe to listens, use the once functionality, or read using the REST API. So if there is the ability to migrate the read path towards listens that are never unsubscribed, that might be a better way to deal with high read bandwidth, although without context of your application I am not sure if that's possible.
Tom