From December 2017 to June 2018 we were engaged as external auditors by Indian Railways to review the public Wi-Fi infrastructure rolled out under RailWire — the Railways–Google partnership announced in 2015 — across the Konkan Railway and the Hubballi railway division. The scope covered over 120 stations, from major junctions to small halts where fibre had reached before road infrastructure did. The work took us into places that don't show up on most business itineraries — stations reachable only by the train line itself, where the road ends a few kilometres short and the approach is on foot or by rail inspection vehicle.
One observation repeated across enough sites to stop feeling like coincidence: the Wi-Fi at remote stations was often noticeably cleaner than at the busy metropolitan ones. Lower latency. Fewer dropped connections. Better throughput on a per-user basis. This is not what most people would guess. The intuition is that remote infrastructure must be worse because everything else in those locations is harder — harder to reach, harder to maintain, harder to power. The Wi-Fi was, in many cases, better anyway. The reason it was better is the interesting part.
What you actually see in the field
Step off the train at a remote station and the physical picture is striking. The platform is small, the building older than you expect, the staff in single digits. There is no road access worth mentioning. And yet above the ticket office, mounted against a concrete pillar, there is a modern enterprise-grade Wi-Fi access point connected to a fibre-optic line that runs kilometres through terrain no vehicle could follow, terminating at a well-designed edge cabinet with proper power conditioning and backup. This is not an accident. The network got built this way because the alternative — patchy, unreliable service at remote stations — was politically unacceptable for a national initiative. So the design choices had to assume failure at every stage and engineer redundancy in anyway.
One moment from those months has stayed with us. Dudhsagar is a small halt station on the Braganza Ghats section in South Goa, inside the Bhagwan Mahaveer Sanctuary. It has a single unsheltered platform, no road access worth the name, and not much else — people reach it by train, or by a 14-kilometre walk along the railway line from Castle Rock. In May 2018, towards the end of the audit window, SSC results had just been declared. We watched a small group of children gathered around their phones on that platform, using the station's free Wi-Fi to check their Class 10 results. The nearest town with reliable connectivity was hours away by road — assuming the road was passable in the first place. For those few minutes, what was supposed to be passenger amenity infrastructure was carrying something else entirely: the weight of whether a teenager from a rail-connected village could find out if they'd passed without their family having to make a day's journey.
That was not an isolated pattern. The free Wi-Fi at stations served travellers as intended, but it also became a de facto public access point for the communities the stations sat in — remote learning content, video calls to family in distant cities, government service portals, exam results — for users who had no realistic alternative.
Why remote often beats metro
The reasons are structural, not miraculous.
Fewer concurrent users per access point. A remote station might serve forty passengers at peak. A major metro terminus serves thousands. Wi-Fi performance scales inversely with user density in ways most deployments fail to account for, and the remote sites simply never hit the density where contention becomes the limiting factor.
Less interference from nearby networks. A metro station sits inside a cloud of overlapping 2.4 GHz and 5 GHz signals — guest hotspots, neighbouring businesses, personal hotspots, public authority networks. A remote station sits in comparative radio silence. The access point can use the entire spectrum allocation it's designed for, not the narrow slice that survives after interference.
Simpler physical environments. A remote station is typically a single-building, single-platform environment. A metro terminus is a multi-level, multi-wing structure with walls, floors and crowds of bodies attenuating signals in unpredictable ways. Coverage design in a simple environment works the first time. In a complex one, it rarely does.
Fibre backhaul without a last-mile bottleneck. The fibre that reaches a remote station usually terminates directly into the station's edge equipment with no intermediate distribution layer that could become a chokepoint. Metro stations, being part of denser infrastructure, often share backhaul across services in ways that make it harder to guarantee Wi-Fi bandwidth specifically.
The remote-station finding doesn't mean those sites are over-engineered. It means the metro sites are under-engineered relative to the demand actually placed on them. The remote sites simply had less demand to fail against.
The design principle underneath
What makes remote-site connectivity work, when it works, is that the design has to assume failure as the baseline. There is no technician twenty minutes away. The replacement part has to be shipped from a regional depot. The alternative backhaul link — if there is one — has to be planned and provisioned in advance, not improvised after an outage. Everything that matters has to be specified before construction, because retrofitting at these sites is prohibitively expensive.
The discipline this forces on the designer is genuinely useful. You start asking questions like:
What happens when the primary fibre is cut by construction work elsewhere on the line? What happens when the mains power goes down for eighteen hours during a monsoon? What happens when the access point itself fails and the nearest replacement is four hours away? What do the staff at the station actually do — what tools and documentation do they have — when the connectivity goes down at 3 AM and no one is watching?
These are not exotic questions. They apply to any organisation where the cost of downtime exceeds the cost of designing against it. Most enterprise networks we audit fail them. Not because the answer is technically hard, but because no one has been forced to ask the questions.
How this translates to corporate and SME infrastructure
The design principles are portable. A corporate office is not a remote railway station, but the logic that makes a remote station work is the same logic that separates a resilient office network from a brittle one.
Redundant backhaul — two internet connections from different providers, on different physical paths where possible — should be a default for any business that can't tolerate a day of downtime. It isn't, in most of the engagements we walk into.
Power conditioning and backup sized for the actual duration of the longest plausible outage in your area, not the shortest. Goa loses mains power for hours at a time during storms; most offices have UPS units sized for minutes.
Documentation that a staff member can follow at 3 AM — runbooks for common failures, named escalation contacts, vendor support numbers within reach of the night desk. The cheapest piece of resilience available and the most consistently missing.
Monitoring the client's own team can read, not a black-box dashboard operated by a vendor. If you can't tell whether your network is healthy without calling someone, you don't actually have monitoring — you have a dependency.
The lesson we took with us
The engagement changed how we approached every subsequent network design. Not because it taught us new technology — the components involved are not exotic — but because it made explicit the difference between building a network and designing one that will survive. Most networks in Indian SMEs and corporate offices are built, not designed in this deeper sense. They work on day one. They stop working gracefully when something unexpected happens, often years later, when the person who set them up is no longer available to explain what was assumed and what was overlooked.
Remote-site infrastructure, for all its physical constraints, doesn't get to make those compromises. What it proves — at every remote station where the Wi-Fi quietly works better than it has any business to — is that designing against failure is cheaper, over the life of the system, than cleaning up after it. That lesson applies equally in a corporate office, a hotel, or a 200-bed hospital. Most of them just haven't been forced to learn it yet.