Pics, velocitat i puntualitat: els secrets del backend de Shotl

A Shotl, moure bé les persones no depèn només de mapes i vehicles. Entre bastidors hi ha un «motor invisible» que manté l'app en funcionament, fa que els temps siguin fiables i garanteix que el servei continuï operatiu passi el que passi. Avui parlem amb Ferran Carril, Platform Engineering Lead de Shotl, per entendre com aconseguim una robustesa que els usuaris noten sense haver de pensar en la tecnologia.

1. Ferran, per començar, per a qui no et conegui: què has fet abans i quina experiència aportes avui a Shotl? He treballat sobretot en equips de plataforma en què la disponibilitat era realment crítica: marketplaces, sistemes en temps real i infraestructures que havien d'escalar sota pressió. Sempre m'he centrat a construir sistemes que no només funcionin en condicions ideals, sinó que continuïn funcionant quan fallen les suposicions. A Shotl, això es tradueix a dissenyar plataformes avorrides en el millor sentit: previsibles, resilients i fàcils d'evolucionar sense ensurts. Automatitzar els processos propensos a errors humans és la meva manera de treballar.
2. Quan diem que Shotl és «robust», què significa realment per a un passatger un dilluns a les 8:00? Significa que l'app respon ràpid, que les ETA són creïbles i que els viatges no desapareixen de sobte només perquè la demanda és alta. Des del punt de vista del passatger, la robustesa es nota en el fet que no passa res d'inesperat. Ni bloquejos, ni cancel·lacions sobtades per problemes del backend, ni missatges de «torna-ho a provar més tard» quan ja fa tard a la feina.
3. Si falla un proveïdor extern (mapes, pagaments, notificacions), com evitem que el servei caigui per a l'usuari? Partim de la base que els proveïdors externs fallaran, perquè fallen. Els aïllem darrere de límits clars i hi afegim timeouts, alternatives i modes degradats. Per exemple, si un servei de mapes va lent, no bloquegem tot el flux de la petició: recorrem a dades en memòria cau o aproximades. L'objectiu és simple: que falli una dependència no hauria de fer caure mai tot el sistema.
4. Quines decisions es prenen perquè l'«essencial» no s'aturi mai, encara que falli alguna cosa secundària? Definim de manera explícita què és essencial i què és desitjable. La creació de viatges, l'assignació de vehicles i les actualitzacions en temps real es tracten de manera molt diferent de l'analítica, els logs o les notificacions no crítiques. L'essencial té prioritat en recursos, reintents i protecció. Els sistemes secundaris poden fallar ràpid o desactivar-se temporalment sense impacte per a l'usuari.
5. Com integreu una millora o un flux nou en qüestió de setmanes sense trencar el que ja funciona? Amb canvis petits i reversibles. Ens recolzem molt en feature flags, desplegaments graduals i API compatibles amb versions anteriors. Res no es desplega de cop. Si un canvi no es pot revertir ràpidament, no està llest per sortir.
6. En hora punta, com aconsegueix el sistema «més múscul» de manera automàtica? Escalem horitzontalment. Quan augmenta el trànsit, afegim automàticament més capacitat de càlcul (més instàncies, més workers) en funció de senyals de demanda reals. És una combinació de regles d'autoescalat, proves de càrrega i ajust constant perquè l'escalat es produeixi abans que els usuaris ho notin, no després.
7. Què és un «marge de capacitat» en el teu dia a dia i com ens protegeix davant de pics inesperats? Un marge de capacitat és capacitat que mantenim deliberadament sense fer servir i disponible en tot moment. És el que absorbeix els pics sobtats de demanda, les incidències o els alentiments sense una degradació immediata. Funcionar sempre al 95 % d'utilització sembla eficient sobre el paper, però és fràgil. El marge és el que ens dona temps de reacció quan la realitat no coincideix amb les previsions.
8. Com decideixes quanta capacitat extra cal mantenir sense disparar els costos? Fixant-me en els patrons d'ús reals, no en pics hipotètics. Analitzem els pics històrics, les tendències de creixement i els escenaris de fallada, i triem un marge que cobreixi els pitjors casos realistes. Sempre és un equilibri: una mica de sobredimensionament surt més barat que una caiguda del servei, però sobredimensionar a cegues és pur malbaratament. Revisem aquestes xifres constantment.
9. Quines mètriques senzilles expliquen millor la qualitat del servei (temps d'espera, puntualitat, cancel·lacions) i com les milloreu? El temps d'espera, la precisió de les ETA i el temps de viatge a bord expliquen la major part de la història. Les seguim d'extrem a extrem i les correlacionem amb el comportament del sistema: càrrega, latència i taxes d'error. Millorar-les no sol dependre d'una gran solució, sinó d'eliminar petites fonts de fricció a tot l'stack.
10. Si ho haguessis de resumir en una promesa a l'usuari: què pot esperar de Shotl pel que fa a robustesa i capacitat d'adaptació? Pot esperar que el servei es comporti de manera coherent, fins i tot quan la demanda es dispara o canvien les condicions. No prometem la perfecció, perquè no és realista, però sí que prometem que les fallades queden contingudes, que la recuperació és ràpida i que les millores no es fan a costa de la fiabilitat.

La tecnologia de Shotl aspira a ser invisible: que tot funcioni, sempre. Gràcies a en Ferran per traduir-ho a un llenguatge senzill i accessible.

Si vols saber-ne més sobre com treballem a Shotl, pots escriure'ns a hello@shotl.com