We are developing a system for the retail market and of its features will enable clients (actually consumer clubs) to go through all transactions made by end-clients.

One of the ways to get this information will be via an API.

The idea is that there will be requests for reports with a start date and an end date, and a response will have all the transactions between those dates.

We worry that some reports will be very large, and that some clients will repeatedly request for reports, in this case the DB and CPU will be very overloaded.

The same server that is going to service those requests will also take care of the actual retail transactions (received by proprietary devices) and of the Web application.

We are not sure about how to limit the report requests from the API so that it won't affect the system too much.

So, how should we deal with this scenario? any thoughts?


just to make it clear: When I mentioned proprietary devices I meant "On-Location" devices which are used during sales with end-clients, this means that these requests shouldn't get delayed, and this is the main concern.

One more question : Some people here suggested the use of prioritized threads, i.e. - giving lower priority to the threads retrieving the reports, is this a good idea?

3 Answers 3


If you make a business rule such that 1 customer may ask for at most 3 reports a day and the total duration of dates in between is not greater than 30, then you could design a table that the system checks before a report request is processed.

A better approach to study the reporting requirement a bit further and consider an Data Mart approach. Move the data to the data mart sever and let the users run the reports as much as they want from the data mart server. Of course this will require more work but it is the better approach from an architecture perspective and it will help your customers with other reporting needs too in the future.

  • is there any advantage in using prioritized threads? I read that it's not reliable, but we here think that the reports are really less important than other tasks, so we thought it may be a good option...
    – Mithir
    Commented Nov 21, 2011 at 7:26
  • I really don't know about that - I suggest you add this to your question may be someone else could help more.
    – NoChance
    Commented Nov 21, 2011 at 7:31

Limit the API access to the most recent: day, week, month, whatever volume you can handle. Anything older could be provided in prebuilt compressed files from an ftp archive site. The limitation of course is changing the format of the archived files.

Do they just need the data to pull into their own analysis and reporting systems or are you providing the code for querying the data?

  • the plan for now is to only supply the raw data
    – Mithir
    Commented Nov 21, 2011 at 7:02

There's something called a "waterfall diagram" (not to be confused with waterfall software development methodology). It has time on the X axis, and activities on the Y axis, like this:

Activity A---->|
               |--- Activity B --->|
                                   | --- Activity C --->|

There are tools to get this, but basically it's a matter of logging the start and end times of the various activities of a transaction, such as fetching stuff from the DB, sending stuff to the client, waiting for the client to execute the code, etc.

The key is that all these steps are sequential, adding up to the total time.

This can tell you if there is any unnecessary delay, such as is caused by one thread or process waiting on another without absolutely needing to, across multiple machines and connections.

If you use a technique like this, you can quickly get to the bottom of any unnecessary latencies.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.