I believe these issues are better addressed by proper PI System Administration and I think custom development in data access layers (i.e, AF and/or PI OLEDB) should not be used for this purpose.
For instance, this TechSupport Knowledge Base article describes some tuning parameters that may be relevant to address the possible issues you mentioned.
Daniel has pointed you already to important information on the tech support site. Let me add that you can extensively monitor your PI System by interfaces that are shipped with the server. I suggest you make yourself familiar with the PI Performance Monitor Interface (%PIHOME%\Interfaces\PIPerfMon_Basic). There is a plug-in for PI SMT (IT Points->Performance Counters) that comes with some templates to monitor for example a PI Server. This will consume some Tags but it is very useful information on what is going on, where are bottlenecks, etc. You might as well take a look at Brian's blog post.
The first step would be to provide some indication on how much data you are retrieving, how many clients do retrieve data and what are the requirements you are facing. Remember, the PI System spans from some hundred tags to millions of tags, from data with frequencies in the range of 1 value every so many minutes to sub second data. This makes it hard to decide whether this could be an issue or not. However, it is always a valid concern.
perhaps you know it already and it does not suit your problem, but there is a setting in PI SMT (Operation | "Tuning Parameters") which restricts the amount of delivered events per query to 150.000 by default. You may customize it to your needs, but I fear the data consumers will then send two queries instead of one.
My idea in a case like yours is to use more hardware power. What about using a collective and addressing specifiv secondary servers to specific departments?