Public Transit Is the Best Available Blueprint for Software That Has to Survive Bad Days

Most software is designed for conditions that hold. Public transit cannot be, because it runs continuously inside real-world uncertainty with almost no tolerance for failure. Services have to keep moving through delays, connectivity outages, hardware faults and severe weather, while absorbing fluctuating demand, shifting government policy and whatever the industry does next.

Miroslav Katsarov, chief executive of Modeshift, which builds intelligent transportation systems for small and mid-size transit agencies, argues that this makes transit a practical model for anyone building systems that have to adapt, recover and keep running when conditions do not cooperate.

Data as an operating instrument, not a report

Data sits at the centre of transit operations in a way it does not in most businesses. It keeps vehicles on schedule and gives authorities what they need for daily decisions, rather than for quarterly review.

Real-time feeds power live passenger information and third-party apps through open formats such as GTFS-Realtime, and simultaneously drive computer-aided dispatch and automatic vehicle location software.

The part worth borrowing is what that does for development. Engineers can watch live metrics to see how a new feature behaves under actual conditions, instead of reasoning about it through a rigid model that assumes the network is up and every vehicle reports on time.

Ticket gates, displays and safety systems keep working when the connection does not

Systems that fix themselves

Once real-time data is genuinely available, it becomes possible to build systems that anticipate problems rather than report them afterwards.

That means tools which predict demand, adjust capacity, and deploy self-healing mechanisms such as automated failover to prevent a partial fault becoming a total outage. The objective is high availability with minimal human intervention, which in a transit context is not a cost-saving measure. It is the only workable model, because there is nobody standing by at three in the morning to restart a ticket gate.

The same data monitors system health, surfaces bugs and personalises the passenger experience. Tracking behaviour across the network and through third-party apps lets an authority find the friction points and adjust, which is ordinary product practice applied to infrastructure.

Designing for the connection being gone

The most transferable engineering is what transit does about connectivity, because it assumes the connection will fail rather than hoping it will not.

Networks handle outages through local edge computing, onboard data caching and graceful offline degradation. Processing happens instantly on the vehicle or at the terminal, without a round trip to a cloud platform, which is why ticket gates, displays and safety systems continue operating through a power cut.

Terminals and vehicles hold fare data, schedules and validation logs locally, then synchronise transactions and updates once the connection returns. Nothing is lost and nothing stops.

Hardware faults get the same treatment: fail-safe designs, automatic switchover, and dual-path communications so that a single broken link does not remove a service.

Why most software does not work this way

None of these techniques is exotic. Edge processing, local caching, offline degradation and automatic failover are all well understood, and most engineering teams could implement them.

They do not, because the incentives point elsewhere. A consumer application that fails during an outage produces an apologetic status page and a bad afternoon. The cost of degrading badly is low enough that designing for the bad day rarely survives prioritisation.

Transit has no such option. A fare system that stops working during a storm strands people, so the failure modes get engineered first and the features arrive afterwards.

That ordering is the actual lesson, and it is a product decision rather than a technical one. Resilient systems are not built by teams with better tools. They are built by teams that were never allowed to assume the good case.