Een inschatting maken van de invoering van een rate limit
Hoe u de invoering van een rate limit kunt inschatten: drempelwaarden, testperiodes, communicatie met klanten. Het schrijven van de code kost een halve dag; het bepalen van limieten waar niemand over klaagt, is het echte werk.
Het programmeren duurt een halve dag. De implementatie duurt twee maanden.
Rate limits zijn eenvoudig te implementeren, maar moeilijk in de praktijk te brengen. De middleware is een bekend patroon. Het lastige deel is het vaststellen van drempels waar niemand over klaagt, en de enige manier om die te bepalen is door het huidige gebruik te meten, de limieten van tevoren aan te kondigen, tijdens een proefperiode te kijken wie er wel geblokkeerd zou zijn, degenen die hierover klagen tegemoet te komen, en pas daarna de limieten daadwerkelijk te handhaven. Die volgorde vormt het eigenlijke werk, en dat past niet in een sprint.
Teams die de middleware inschatten, missen de implementatie volledig. Teams die de implementatie inschatten, komen uit op een veel hoger aantal, vragen zich af of het daadwerkelijk urgent is, en besluiten meestal om het in meerdere cycli uit te voeren — wat de juiste aanpak is. Door het geheel in één keer in te schatten, wordt het team in een valse tweedeling gedwongen.
Wat er in de kamer wordt gezegd
Backend: “De middleware is een dag. We beschikken over een bibliotheek.”
SRE: “Welke drempelwaarden? Hebben we al gekeken naar p99 van het huidige verbruik?”
PM: „Aan wie moeten we een e-mail sturen voordat dit in werking treedt?”
Ondersteuning: “Wat staat er in de 429-respons? Is er een ‘retry-after’?”
Kop: „Eerst een proefperiode, of meteen handhaven?”
Vragen die u zich het beste kunt stellen voordat u gaat stemmen
- Hebben wij het stroomverbruik gemeten — p50, p95 en p99 per klant?
- Welke drempelwaarden — en hoe zijn deze vastgesteld?
- Per account, per IP-adres, per API-sleutel? Combinaties?
- Proefperiode: hoe lang duurt deze, en wat wordt verstaan onder „geen verrassingen“?
- Communicatie met klanten: naar wie sturen wij een e-mail, en hoe lang van tevoren?
- Hoe ziet het 429-antwoord eruit — bericht, tijd tussen pogingen, link naar documentatie?
- Wat is de alternatieve procedure voor een klant die een hogere limiet nodig heeft?
Splits het op: handhaving is één aspect, een proefdraaien in combinatie met communicatie is een ander aspect, en het afstemmen van drempelwaarden is een derde aspect. Elk aspect is op zichzelf omvangrijk; het geheel als zodanig is dat niet.
Stem de omvang af op de uitrol, niet op de middleware. Het gaat om het meten, het aankondigen en het doorvoeren van proefdraaien.
Zie het inschatten van de uitrol van een feature-flag voor hetzelfde patroon waarbij de uitrol het werk opslokt, en de andere praktische voorbeelden van schattingen. Start een gratis planning poker-sessie zodra de fasen zijn benoemd.