Comment devons-nous traiter avec plusieurs demandes de rapport de transaction?

Question

Nous développons un système pour le marché de détail et ses fonctionnalités permettra aux clients (en fait des clubs de consommateurs) de passer par toutes les transactions effectuées par les clients finaux.

L'une des façons d'obtenir ces informations sera via une API.

L'idée est qu'il y aura des demandes de rapports avec une date de début et une date de fin, et une réponse aura toutes les transactions entre ces dates.

Nous craignons que certains rapports soient très importants et que certains clients demanderont à plusieurs reprises des rapports, dans ce cas, la DB et le CPU seront très surchargés.

Le même serveur qui va desservir ces demandes s'occupera également des transactions de vente au détail réelles (reçues par les appareils propriétaires) et de l'application Web.

Nous ne savons pas comment limiter les demandes de rapport de l'API afin qu'elle n'affecte pas trop le système.

Alors, comment devons-nous gérer ce scénario? Des pensées?

ÉDITER:

Juste pour indiquer clairement: lorsque j'ai mentionné les appareils propriétaires, je voulais dire les appareils «sur place» qui sont utilisés pendant les ventes avec des climents finaux, cela signifie que ces demandes ne devraient pas être retardées, et c'est la principale préoccupation.

Une autre question: certaines personnes ici ont suggéré l'utilisation de fils prioritaires, c'est-à-dire - accordés de priorités plus faibles aux discussions pour récupérer les rapports, est-ce une bonne idée?