Picchi, velocità e puntualità: i segreti del backend di Shotl

In Shotl, muovere bene le persone non dipende solo da mappe e veicoli. Dietro le quinte c'è un «motore invisibile» che mantiene l'app in funzione, rende affidabili i tempi e garantisce che il servizio resti attivo, qualunque cosa accada. Oggi parliamo con Ferran Carril, Platform Engineering Lead di Shotl, per capire come offriamo quella robustezza che gli utenti percepiscono senza dover pensare alla tecnologia.

1. Ferran, per iniziare, per chi non ti conosce: di che cosa ti sei occupato in passato e quali competenze porti oggi in Shotl? Ho lavorato soprattutto in team di piattaforma dove la disponibilità contava davvero: marketplace, sistemi in tempo reale e infrastrutture che dovevano scalare sotto pressione. Mi sono sempre concentrato sulla costruzione di sistemi che non funzionino solo in condizioni ideali, ma che continuino a funzionare quando le ipotesi non reggono più. In Shotl questo si traduce nel progettare piattaforme noiose nel senso migliore del termine: prevedibili, resilienti e facili da far evolvere senza drammi. Automatizzare i processi soggetti a errori umani è il mio modo di lavorare.
2. Quando diciamo che Shotl è «robusta», che cosa significa concretamente per un passeggero di lunedì alle 8:00? Significa che l'app risponde rapidamente, che gli ETA sono credibili e che le corse non spariscono all'improvviso solo perché la domanda è alta. Dal punto di vista del passeggero, la robustezza si manifesta nel fatto che non succede niente di inatteso. Nessun blocco, nessuna cancellazione improvvisa dovuta a problemi del backend, nessun messaggio «riprova più tardi» quando si è già in ritardo per il lavoro.
3. Se un fornitore esterno non funziona (mappe, pagamenti, notifiche), come evitiamo che il servizio si interrompa per l'utente? Partiamo dal presupposto che i fornitori esterni avranno problemi, perché succede. Li isoliamo dietro confini chiari e aggiungiamo timeout, soluzioni di ripiego e modalità degradate. Per esempio, se un servizio di mappe è lento, non blocchiamo l'intero flusso della richiesta: ripieghiamo su dati in cache o approssimati. L'obiettivo è semplice: il guasto di una singola dipendenza non deve mai trascinare con sé l'intero sistema.
4. Quali scelte vengono fatte perché l'«essenziale» non si fermi mai, anche se qualcosa di secondario si guasta? Definiamo esplicitamente che cosa è essenziale e che cosa è accessorio. La creazione delle corse, l'assegnazione dei veicoli e gli aggiornamenti in tempo reale sono trattati in modo molto diverso rispetto all'analisi dei dati, ai log o alle notifiche non critiche. L'essenziale ha la priorità in termini di risorse, tentativi e protezione. I sistemi secondari possono fallire rapidamente o essere disattivati temporaneamente senza impatto sull'utente.
5. Come integrate un miglioramento o un nuovo flusso nel giro di poche settimane senza rompere ciò che già funziona? Mantenendo le modifiche piccole e reversibili. Ci affidiamo molto a feature flag, rilasci graduali e API retrocompatibili. Niente viene rilasciato tutto in una volta. Se una modifica non può essere annullata rapidamente, non è pronta per essere rilasciata.
6. Nelle ore di punta, come fa il sistema a dotarsi automaticamente di «più muscoli»? Scaliamo orizzontalmente. Quando il traffico aumenta, aggiungiamo automaticamente capacità di calcolo (più istanze, più worker) sulla base di segnali di domanda reali. È un mix di regole di autoscaling, test di carico e ottimizzazione costante, in modo che lo scaling avvenga prima che gli utenti ne risentano, non dopo.
7. Che cos'è un «margine di capacità» nel tuo lavoro quotidiano e come ci protegge dai picchi imprevisti? Un margine di capacità è una capacità volutamente inutilizzata che teniamo sempre disponibile. È ciò che assorbe picchi improvvisi di domanda, incidenti o rallentamenti senza un degrado immediato. Far girare tutto al 95% di utilizzo sembra efficiente sulla carta, ma è fragile. Il margine è ciò che ci dà il tempo di reagire quando la realtà non corrisponde alle previsioni.
8. Come decidi quanta capacità extra mantenere senza far lievitare i costi? Guardando ai modelli di utilizzo reali, non a picchi ipotetici. Analizziamo i picchi storici, le tendenze di crescita e gli scenari di guasto, e poi scegliamo un margine che copra i casi peggiori realistici. È sempre un compromesso: un po' di sovradimensionamento costa meno di un disservizio, ma sovradimensionare alla cieca è solo uno spreco. Rivediamo questi numeri di continuo.
9. Quali metriche semplici spiegano meglio la qualità del servizio (tempo di attesa, puntualità, cancellazioni) e come le migliorate? Tempo di attesa, precisione degli ETA e tempo di viaggio a bordo raccontano gran parte della storia. Li monitoriamo end-to-end e li mettiamo in relazione con il comportamento del sistema: carico, latenza e tassi di errore. Migliorarli di solito non dipende da un unico grande intervento, ma dall'eliminazione di piccole fonti di attrito lungo tutto lo stack.
10. Se dovessi riassumerlo in una promessa all'utente: che cosa può aspettarsi da Shotl in termini di robustezza e capacità di adattamento? Può aspettarsi che il servizio si comporti in modo coerente, anche quando la domanda aumenta all'improvviso o le condizioni cambiano. Non promettiamo la perfezione, perché non sarebbe realistico, ma promettiamo che i guasti restano circoscritti, che il ripristino è rapido e che i miglioramenti non vanno a scapito dell'affidabilità.

La tecnologia di Shotl punta a essere invisibile: tutto funziona, sempre. Grazie a Ferran per averla tradotta in un linguaggio semplice e accessibile.

Se vuoi saperne di più su come lavoriamo in Shotl, puoi contattarci all'indirizzo hello@shotl.com