Het inschatten van de invoering van een rate limit

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 observeren wie er wel zou zijn geblokkeerd, de luidruchtigste klagers tegemoet te komen en pas daarna de limieten daadwerkelijk te 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 meestal om het in meerdere cycli uit te voeren, wat de juiste aanpak is. Het in één keer inschatten van het geheel dwingt het team tot een valse tweedeling.

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 direct handhaven?”

Vragen die het waard zijn om te stellen voordat u gaat stemmen

• Hebben wij het stroomverbruik per klant gemeten op p50, p95 en p99?
• Welke drempelwaarden, en hoe zijn deze vastgesteld?
• Per account, per IP-adres, per API-sleutel? Combinaties?
• Proefperiode: hoe lang duurt deze, en wat wordt er 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?

Laten we het opsplitsen: handhaving is één aspect, een proefdraai plus communicatie is een ander aspect, en het afstemmen van de 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 voorbeelden van schattingen die in de praktijk zijn toegepast. Start een gratis planning poker-sessie zodra de fasen een naam hebben gekregen.