Het inschatten van de invoering van een rate limit

Het schrijven van de code 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 is het vaststellen van drempels waar niemand bezwaar tegen heeft, en de enige manier om die te bepalen is het meten van het huidige gebruik, de limieten vooraf aankondigen, tijdens een proefperiode observeren wie er zou zijn geblokkeerd, de luidruchtigste gebruikers hierover aanspreken en pas daarna de regels handhaven. Die volgorde vormt het eigenlijke werk, en dat past niet binnen 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 doorgaans om deze over meerdere cycli te spreiden, 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 wij 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 het waard zijn om te stellen voordat u gaat stemmen

• Hebben wij het stroomverbruik op p50, p95 en p99 per klant gemeten?
• Welke drempelwaarden, en hoe zijn deze vastgesteld?
• Per account, per IP-adres, per API-sleutel? Combinaties?
• Proefperiode: hoe lang duurt deze, en wat wordt onder „geen verrassingen” verstaan?
• 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 procedure voor een klant die een hogere limiet nodig heeft?

Splits het: handhaving is één aspect, een proefdraai 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.

Richt u op de schaal van de implementatie, niet op de middleware. Het gaat om het meten, het bekendmaken 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 praktijkvoorbeelden van schattingen. Start een gratis planning poker-sessie zodra de fasen zijn benoemd.