Spikes, speed, and punctuality: secrets of Shotl’s backend

At Shotl, moving people well isn’t just about maps and vehicles. Behind the scenes there’s an “invisible engine” that keeps the app running, makes timings reliable, and ensures the service stays up—no matter what. Today we’re speaking with Ferran Carril, Shotl’s Platform Engineering Lead, to understand how we deliver the kind of robustness users feel without having to think about the technology.

1. Ferran, to kick off, for those who don’t know you: what have you done before, and what expertise do you bring to Shotl today?

   I’ve mostly worked on platform teams where availability actually mattered — marketplaces, real-time systems, and infrastructure that had to scale under pressure. My focus has always been on building systems that don’t just work in ideal conditions, but keep working when assumptions break. At Shotl, that translates into designing platforms that are boring in the best sense: predictable, resilient, and easy to evolve without drama. Automating processes prone to human errors is my way to go.

2. When we say Shotl is “robust,” what does that actually mean for a passenger on a Monday at 8:00 a.m.?

   It means the app responds quickly, ETAs are credible, and trips don’t randomly disappear just because demand is high. From a passenger’s perspective, robustness shows up as nothing surprising happening. No freezes, no sudden cancellations due to backend issues, no “try again later” messages when they’re already late for work.

3. If an external provider fails (maps, payments, notifications), how do we keep the service from going down for the user?

   We assume external providers will fail — because they do. We isolate them behind clear boundaries, add timeouts, fallbacks, and degraded modes. For example, if a mapping service is slow, we don’t block the entire request flow; we fall back to cached or approximate data. The goal is simple: one dependency failing should never take the whole system with it.

4. What decisions are made so that the “essentials” never stop, even if something secondary fails?

   We explicitly define what’s essential versus nice to have. Trip creation, vehicle assignment, and real-time updates are treated very differently from analytics, logging, or non-critical notifications. Essentials get priority in terms of resources, retries, and protection. Secondary systems are allowed to fail fast or be temporarily disabled without user impact.

5. How do you integrate an improvement or a new flow in a matter of weeks without breaking what already works?

   By keeping changes small and reversible. We rely heavily on feature flags, gradual rollouts, and backward-compatible APIs. Nothing is “big bang” deployed. If a change can’t be rolled back quickly, it’s not ready to ship.

6. At rush hour, how does the system automatically get “more muscle”?

   We scale horizontally. When traffic increases, we add more compute capacity automatically — more instances, more workers — based on real demand signals. It’s a mix of autoscaling rules, load testing, and constant tuning so that scaling happens before users feel pain, not after.

7. What is a “resource buffer” in your day-to-day, and how does it protect us against unexpected spikes?

   A resource buffer is deliberately unused capacity we keep available at all times. It’s what absorbs sudden demand spikes, incidents, or slowdowns without immediate degradation. Running everything at 95% utilization looks efficient on paper, but it’s fragile. The buffer is what buys us reaction time when reality doesn’t match forecasts.

8. How do you decide how much extra capacity to maintain without driving up costs?

   By looking at real usage patterns, not peak hypotheticals. We analyze historical spikes, growth trends, and failure scenarios, then choose a buffer that covers realistic worst cases. It’s always a trade-off: some over-provisioning is cheaper than outages, but blind over-provisioning is just waste. We revisit these numbers constantly.

9. Which simple metrics best explain service quality (wait time, punctuality, cancellations), and how do you improve them?

   Wait time, ETA accuracy, and travelling on-board time tell most of the story. We track them end-to-end and correlate them with system behavior — load, latency, error rates. Improving them is usually less about one big fix and more about removing small sources of friction across the stack.

10. If you had to sum it up as a promise to the user: what can they expect from Shotl in terms of robustness and adaptability?

    They can expect the service to behave consistently, even when demand spikes or conditions change. We won’t promise perfection — that’s unrealistic — but we do promise that failures are contained, recoveries are fast, and improvements don’t come at the cost of reliability.

Shotl’s technology aims to be invisible: everything just works, always. Thanks to Ferran for translating it into plain, accessible language.

If you’d like to learn more about how we operate at Shotl, you can contact us at hello@shotl.com