The Physics of Latency
Data doesn't travel at the speed of thought. It travels at roughly 200,000 kilometres per second through fibre optic cable — about two-thirds the speed of light in vacuum, accounting for the refractive index of glass. The distance between Mumbai and a data centre in Iowa is approximately 13,500 kilometres. At those physics, the theoretical minimum one-way latency is around 67 milliseconds. Round-trip is at least 134ms, before you add protocol overhead, routing hops, server processing time, and the last-mile variance of Indian mobile networks.
In practice, India-to-US-East round-trip times often land between 180ms and 300ms in real-world conditions. This is a consequence of physics, not of poor engineering. The earth is large and the speed of light is fixed. There is no software optimisation that makes Iowa closer to Mumbai.
Now compare that to a Firebase backend in asia-south1, located in Mumbai. The round-trip from an Indian device to Mumbai infrastructure can be as low as 20–40ms on a good connection. That's not a marginal improvement. That's an order-of-magnitude difference in the time it takes your app to talk to its backend.
What 80ms vs 20ms Feels Like in Practice
Latency at these scales is not perceived as "slow." It's perceived as something else: unresponsiveness, or a lack of snap, or a feeling that the app isn't quite keeping up with you. It's rarely legible as "the server is far away." But the experience of an app that responds in 20ms is genuinely different from the experience of one that responds in 80ms, and users feel that difference even when they can't articulate it.
For Twunein, where the core experience depends on real-time sync, this isn't an abstract concern. The sync mechanism involves multiple reads and writes to the shared session state, in rapid succession, as users interact with the player. Each one of those interactions has a round-trip. If each round-trip costs 80ms more than it needs to, those costs accumulate into an experience that feels slower and less precise than it should be.
The specific case where latency matters most is the moment of joining a session — when a user opens the app, connects to an in-progress session, and needs to calculate where in the song their partner currently is. That calculation requires a read from the session state, a comparison with the local time, and a seek to the correct position. If the read takes 80ms extra because the server is far away, the join experience feels sluggish. If it takes 20ms, it feels instant. The user doesn't know why. They know whether it felt right.
The Undersea Cable Reality
Most people have an abstract sense that the internet involves cables between countries, without a concrete picture of what that means for their daily app usage. The specific cables involved in India-to-US traffic — the SEAMEWE series, the AAG cable, others — are shared infrastructure that carries enormous volumes of traffic simultaneously. They're not congested in the way that a local cell tower can be, but they are subject to routing decisions, peering arrangements, and maintenance windows that can affect latency unpredictably.
This is part of why India-to-US latency varies so much in practice. On a good day, on good routing, 180ms round-trip is achievable. On a day with congested peering or a suboptimal route, 300ms or more is possible. When you're building real-time infrastructure, that variance is as important as the baseline. An app that works well on average but badly on variance is an app that unreliably fails a fraction of your users in ways that are hard to reproduce and diagnose.
Infrastructure in Mumbai doesn't eliminate variance, but it reduces the surface area where variance can occur. The path from a Bangalore device to a Mumbai data centre is short, well-provisioned, and largely domestic. The number of routing hops is smaller. The peering arrangements are more predictable. The result is lower variance, not just lower baseline latency — which is, for real-time applications, arguably the more important property.
Firebase's India Regions
Firebase offers asia-south1 (Mumbai) and asia-south2 (Delhi) as regions for Indian deployments. This is relatively recent infrastructure — Google's investment in Indian data centre capacity has expanded significantly over the past few years — and it makes Firebase a more viable choice for Indian-first apps than it was even three years ago.
The region choice matters differently for different Firebase services. Firestore latency is directly tied to region. Cloud Functions cold-start times and invocation latency are region-dependent. Not all Firebase services need to be in the same region, but careful thought about which services your app calls most frequently — and how latency-sensitive those calls are — determines how much your region choices matter.
For Twunein, the session state management is the most latency-sensitive component. Everything else can tolerate some additional delay. So the priority was ensuring the real-time infrastructure is in India. The less latency-sensitive backend components can be configured based on other considerations — cost, feature availability, data residency requirements — without the same urgency.
Infrastructure as a Respect Decision
I want to make an argument that goes beyond the technical: infrastructure placement is a respect decision, not just a performance optimisation. When you choose to deploy in India rather than defaulting to a US-East region because that's where Firebase's earliest and most-featured infrastructure was, you're saying something to your users. You've thought about where they are. You've considered what their experience feels like. You've paid for proximity because they deserve it.
This might sound philosophical for what is, at its core, a dropdown in a console. But these small choices compound. An Indian developer building for Indian users who defaults to us-central1 out of inertia is leaving latency on the table that their users have to pay for in every session. The inertia is understandable — us-central1 is where the documentation examples often point, where StackOverflow answers assume you are. But inertia isn't a good enough reason when the cost falls on your users.
Data localisation under the DPDPA 2023 adds a regulatory dimension to infrastructure choices for certain categories of data. But even without regulatory pressure, the case for India-region infrastructure for Indian-user apps is strong on pure performance grounds. The regulation makes it a compliance matter in some cases. The physics make it the right call in all cases.
The Tradeoff Conversation
Regional infrastructure choices involve real tradeoffs, and it's worth being honest about them. Some Firebase features are not available in all regions — or are not available in india regions with the same maturity and stability as us-central1. New Firebase features often roll out to US regions first, with international regions following weeks or months later. If you need to use a preview feature that isn't yet available in asia-south1, you're making a tradeoff.
The right way to think about this: identify the latency-critical components of your app and optimise those for proximity. Accept that some peripheral components may need to be in a different region, and design your architecture to minimise the number of latency-critical calls that cross regional boundaries. For most Indian apps, the latency-critical path is narrow enough that this is manageable without significant architectural complexity.
What's not a good tradeoff is defaulting to us-central1 for everything because it's familiar. Your users feel that default. They feel it as "this app is slightly slow," as "this doesn't quite snap," as the app they used for a while and then uninstalled for one that felt faster, without knowing why. Infrastructure is invisible until it isn't. Getting it right is one of those things that earns you nothing — nobody reviews your region selection on the Play Store — but getting it wrong costs you something real.