La realizzazione del codice richiede mezza giornata. L’implementazione richiede due mesi.

I limiti di velocità sono facili da implementare ma difficili da rendere operativi. Il middleware è un modello ben noto. La parte difficile consiste nello stabilire soglie che non suscitino lamentele, e l’unico modo per farlo è misurare l’utilizzo attuale, annunciare i limiti in anticipo, osservare durante un periodo di prova chi sarebbe stato bloccato, dare voce a chi si lamenta e solo allora applicare le restrizioni. Questa sequenza di operazioni richiede un certo impegno e non rientra nei tempi di uno sprint.

I team che valutano il middleware tralasciano completamente la fase di implementazione. I team che valutano l’implementazione ottengono una stima molto più elevata, si chiedono se sia effettivamente urgente e di solito decidono di suddividerla in più cicli — il che rappresenta la risposta corretta. Valutare l’intero progetto in un’unica soluzione costringe il team a una falsa dicotomia.

Ciò che viene detto nella stanza

Backend: «Il middleware è una cosa da poco. Abbiamo una libreria.»

SRE: «Quali soglie? Abbiamo esaminato il p99 dei consumi attuali?»

PM: «A chi dobbiamo inviare un’e-mail prima che questo si attivi?»

Assistenza: “Cosa indica il codice di risposta 429? È previsto un nuovo tentativo?”

Titolo: “Prima la modalità di prova, o si passa direttamente all’applicazione delle norme?”

Domande che vale la pena porsi prima di votare

  • Abbiamo misurato il consumo di corrente — p50, p95, p99 per cliente?
  • Quali sono i valori soglia — e in base a quali criteri sono stati scelti?
  • Per account, per indirizzo IP, per chiave API? Combinazioni?
  • Periodo di prova: quanto dura e cosa si intende per “senza sorprese”?
  • Comunicazioni con i clienti: a chi inviamo le e-mail e con quanto anticipo?
  • Come si presenta la risposta 429: messaggio, intervallo di attesa per il nuovo tentativo, link alla documentazione?
  • Qual è la procedura da seguire per un cliente che necessita di un limite più elevato?

Suddividere: l’applicazione delle regole è una questione a sé stante, la simulazione e la comunicazione ne costituiscono un’altra, mentre la regolazione delle soglie ne rappresenta una terza. Ciascuna di esse è di per sé di notevole entità; l’insieme, invece, non lo è.

Si deve valutare la portata dell’implementazione, non il middleware. La chiave sta nel misurare, comunicare e effettuare simulazioni.

Si veda la stima dell’implementazione di un feature flag per lo stesso schema in cui l’implementazione assorbe il lavoro, nonché gli altri esempi di stime effettuate con successo. Avviare una sessione gratuita di planning poker una volta definite le fasi.