Ik ken de theorie niet onder de naam die Joris noemt, maar ben redelijk goed bekend met het ondersteunen van queue times en load-balancing.
Wat hier nu gebeurd is dat inno van een FIFO (first in, first out) queue naar een on-demand queue gaat. Dit betekent dat voor elke client en elke sessie bijgehouden wordt hoe vaak een actie uitgevoerd wordt en wanneer deze een variabel limiet overschrijd wordt de gebruiker herleid naar een "warning" page.
Waarom dit inno (wellicht) meer kost: FIFO queues zijn heel simpel. De eerste die een request doet krijgt als eerste "antwoord" terug. on-demand queues zijn daarin tegen veel complexer. Op het moment dat jij onder het variabele limiet zit zit je in een FIFO queue, maar anders wordt je herleid. Deze variabelen moeten bijgehouden worden per client (en per sessie). Theoretisch, en daar moet je me niet op vast pinnen, zou het zo moeten zijn dat je op verschillende werelden 10acties per seconde kan doen, zolang het op 1 wereld maar niet meer is dan het variabele limiet.
Het bijhouden is wat voor extra rekenkracht zorgt. Tuurlijk zorgt op momenten van piektijd dat een user die extreem veel requests doet een "warning" page te zien krijgt, maar deze data moet nu ook bijgehouden worden op moment dat er 5users online zijn (en er praktisch 1000requests per seconde gedaan kunnen worden zonder issues)
Iemand moet me verbeteren als ik het verkeerd uitleg. Ben hier redelijk bekend mee, maar nooit in detail op hoeven zetten
dat laat ik aan anderen over
edit: overigens ben ik voorstander dat je je post niet verwijderd. Het is een interessante discussie (vind ik)
edit2: heb joris gepoked even te kijken naar mijn beschrijving
wellicht dat hij het beter kan uitleggen