The App That Broke on Launch Day
A real government app built to ration fuel for a country in crisis, and what its launch-day failure teaches about designing for scale before you need it.
Most serverless design advice stays abstract: think about scale, plan for failure, decouple your components. It's easy to nod along and forget it by the next sprint.
So instead of a made-up example, I want to walk through a real one: National Fuel Pass, an app the Sri Lankan government launched during the country's 2022 fuel crisis. The story of what happened on its first day is the best argument I've seen for taking non-functional requirements seriously before launch, not after.
What the app actually does
Sri Lanka rationed fuel by tying every purchase to a QR code. To get that QR code, you had to register.
The registration flow has six steps.
- Submit an ID and a mobile number. Your national ID, passport, or business registration number, plus the phone number you'll use to log in later.
- Verify the phone with an OTP. No usernames or passwords anywhere in this app, only a one-time password sent by SMS.
- Add personal details. First name, last name, address.
- Add vehicle details. Plate number, vehicle type, chassis number, and whether it runs on petrol or diesel.
- Get verified against an external system. The ID and vehicle details get checked against the Department of Motor Traffic's records before registration can succeed.
- Receive a QR code. From then on, logging in is just a phone number and a fresh OTP, and the QR code is what you show at the pump.
ExpandThe six-step registration flow, ending with an external verification call to the Department of Motor Traffic
Nothing about this flow looks unusual. It's a form, an OTP check, and one call out to a government system to confirm the details are real.
What actually happened
On launch day, more than a million people tried to register within hours.
The system didn't hold up. OTP messages didn't arrive for a large share of users, so people got stuck at step 2 with no way forward. Registrations that did get past the OTP check started failing further down the flow too.
For a country rationing fuel during a crisis, a broken registration page wasn't a minor bug. It was people unable to get fuel for their cars while the queue outside the app grew as fast as the queue outside the filling station.
The team fixed it fast. By the next day, the system was handling the same load without falling over. But the interesting question isn't how they fixed it, it's what the first version of the architecture must have gotten wrong to fail at that scale in the first place.
Why this is the right case study
A form with an OTP check and one external API call sounds simple enough to build in an afternoon. That's exactly what makes it useful here.
The functionality was never the hard part. The hard part was building something that could take a million simultaneous strangers, each one waiting on an SMS that has to arrive within seconds, without the whole system buckling under its own success.
That's the gap between a system that works in a demo and a system that works on launch day. Closing it means being deliberate about the non-functional side, scale, reliability, cost, before writing the first Lambda function, not after the first outage.
The Essentials
- A working demo and a working launch day are different bars. The fuel pass flow is simple enough to build quickly. Surviving a million simultaneous registrations is a separate problem entirely.
- Passwordless, OTP-based auth removes a password database, not the scaling problem. The OTP delivery pipeline itself becomes a dependency that has to scale.
- An external verification call is a hard dependency. Every registration depends on a system you don't control and can't scale yourself.
- Non-functional requirements decide whether launch day survives. Functionality answers what the system does. Scale, reliability, and cost answer whether it still does it under real load.
Further Reading and Watching
Keep reading