Picos, velocidad y puntualidad: los secretos del backend de Shotl

En Shotl, mover bien a las personas no depende solo de mapas y vehículos. Entre bastidores hay un «motor invisible» que mantiene la app en funcionamiento, hace que los tiempos sean fiables y garantiza que el servicio siga operativo pase lo que pase. Hoy hablamos con Ferran Carril, Platform Engineering Lead de Shotl, para entender cómo conseguimos una robustez que los usuarios notan sin tener que pensar en la tecnología.

1. Ferran, para empezar, para quien no te conozca: ¿qué has hecho antes y qué experiencia aportas hoy a Shotl? He trabajado sobre todo en equipos de plataforma donde la disponibilidad era realmente crítica: marketplaces, sistemas en tiempo real e infraestructuras que tenían que escalar bajo presión. Siempre me he centrado en construir sistemas que no solo funcionen en condiciones ideales, sino que sigan funcionando cuando fallan las suposiciones. En Shotl, eso se traduce en diseñar plataformas aburridas en el mejor sentido: predecibles, resilientes y fáciles de evolucionar sin sobresaltos. Automatizar los procesos propensos a errores humanos es mi forma de trabajar.
2. Cuando decimos que Shotl es «robusto», ¿qué significa realmente para un pasajero un lunes a las 8:00? Significa que la app responde rápido, que las ETA son creíbles y que los viajes no desaparecen de repente solo porque la demanda es alta. Desde el punto de vista del pasajero, la robustez se nota en que no pasa nada inesperado. Ni bloqueos, ni cancelaciones repentinas por problemas del backend, ni mensajes de «inténtalo más tarde» cuando ya llega tarde al trabajo.
3. Si falla un proveedor externo (mapas, pagos, notificaciones), ¿cómo evitamos que el servicio se caiga para el usuario? Partimos de la base de que los proveedores externos van a fallar, porque fallan. Los aislamos detrás de límites claros y añadimos timeouts, alternativas y modos degradados. Por ejemplo, si un servicio de mapas va lento, no bloqueamos todo el flujo de la petición: recurrimos a datos en caché o aproximados. El objetivo es simple: que falle una dependencia nunca debería tumbar todo el sistema.
4. ¿Qué decisiones se toman para que lo «esencial» nunca se detenga, aunque falle algo secundario? Definimos de forma explícita qué es esencial y qué es deseable. La creación de viajes, la asignación de vehículos y las actualizaciones en tiempo real se tratan de forma muy distinta a la analítica, los logs o las notificaciones no críticas. Lo esencial tiene prioridad en recursos, reintentos y protección. Los sistemas secundarios pueden fallar rápido o desactivarse temporalmente sin impacto para el usuario.
5. ¿Cómo integráis una mejora o un nuevo flujo en cuestión de semanas sin romper lo que ya funciona? Con cambios pequeños y reversibles. Nos apoyamos mucho en feature flags, despliegues graduales y API compatibles con versiones anteriores. Nada se despliega de golpe. Si un cambio no se puede revertir rápidamente, no está listo para salir.
6. En hora punta, ¿cómo consigue el sistema «más músculo» de forma automática? Escalamos horizontalmente. Cuando aumenta el tráfico, añadimos automáticamente más capacidad de cómputo (más instancias, más workers) en función de señales de demanda reales. Es una combinación de reglas de autoescalado, pruebas de carga y ajuste constante para que el escalado se produzca antes de que los usuarios lo noten, no después.
7. ¿Qué es un «margen de capacidad» en tu día a día y cómo nos protege frente a picos inesperados? Un margen de capacidad es capacidad que mantenemos deliberadamente sin usar y disponible en todo momento. Es lo que absorbe los picos repentinos de demanda, las incidencias o las ralentizaciones sin una degradación inmediata. Funcionar siempre al 95 % de utilización parece eficiente sobre el papel, pero es frágil. El margen es lo que nos da tiempo de reacción cuando la realidad no coincide con las previsiones.
8. ¿Cómo decides cuánta capacidad extra mantener sin disparar los costes? Fijándome en los patrones de uso reales, no en picos hipotéticos. Analizamos los picos históricos, las tendencias de crecimiento y los escenarios de fallo, y elegimos un margen que cubra los peores casos realistas. Siempre es un equilibrio: algo de sobredimensionamiento sale más barato que una caída del servicio, pero sobredimensionar a ciegas es puro desperdicio. Revisamos estas cifras constantemente.
9. ¿Qué métricas sencillas explican mejor la calidad del servicio (tiempo de espera, puntualidad, cancelaciones) y cómo las mejoráis? El tiempo de espera, la precisión de las ETA y el tiempo de viaje a bordo cuentan la mayor parte de la historia. Los seguimos de extremo a extremo y los correlacionamos con el comportamiento del sistema: carga, latencia y tasas de error. Mejorarlos no suele depender de una gran solución, sino de eliminar pequeñas fuentes de fricción en todo el stack.
10. Si tuvieras que resumirlo en una promesa al usuario: ¿qué puede esperar de Shotl en cuanto a robustez y capacidad de adaptación? Puede esperar que el servicio se comporte de forma coherente, incluso cuando la demanda se dispara o cambian las condiciones. No prometemos la perfección, porque no es realista, pero sí prometemos que los fallos quedan contenidos, que la recuperación es rápida y que las mejoras no se hacen a costa de la fiabilidad.

La tecnología de Shotl aspira a ser invisible: que todo funcione, siempre. Gracias a Ferran por traducirlo a un lenguaje sencillo y accesible.

Si quieres saber más sobre cómo trabajamos en Shotl, puedes escribirnos a hello@shotl.com