The Postcode in Your Logs: Let User Geography, Not Guesswork, Pick Your Next Region
Photo: Intel Free Press, CC BY 2.0, via Wikimedia Commons
Ask a founding team where their users are located and you will usually get the same answer: "everywhere." It sounds healthy. It sounds like growth. It is also, in our experience reviewing traffic patterns with hundreds of US-based operators, almost never true.
The reality is that most applications have a gravitational center — a handful of metros that generate the majority of sessions — and the distribution is rarely where the team guessed. The good news is that the evidence is already sitting in your infrastructure, waiting to be read.
Your Assumptions Are Not a Dataset
The trouble with "coast-to-coast" thinking is that it leads to coast-to-coast spending. Teams provision infrastructure in Northern Virginia and Northern California because that is what a national footprint is supposed to look like, then discover that seventy percent of their requests originate from a triangle running through Chicago, Columbus, and Atlanta.
Geography-based guesswork fails for a simple reason: user distribution follows your product's history, not the census. A B2B SaaS tool adopted by one Midwestern manufacturer's whole sales team will skew heavily toward the Twin Cities. A consumer app that got its first traction on a Dallas college campus may still carry that Texas weight years later. You cannot reason your way to this. You have to measure it.
Reading the Map That Already Exists
Start with your request logs, load balancer metrics, or CDN analytics — nearly every provider exposes source geography at some level of granularity. Three views matter more than the rest.
Median latency by metro. Not average, median. Averages are dragged upward by a handful of distant mobile users and will hide exactly the concentration you are looking for. Sort your top metros by median time-to-first-byte and you will immediately see which regions are serving users comfortably and which are stretching across two thousand miles of fiber.
Request volume per capita. Raw traffic volume tells you where your biggest metros are. Volume relative to population tells you where your product is unusually popular — the Ohio phenomenon. A mid-sized city punching well above its weight in requests per thousand residents is a signal worth understanding before you spend a dollar on new infrastructure.
Peak-hour alignment. Plot your daily traffic curve against time zone. If your load spikes at 9 a.m. Pacific and 9 a.m. Eastern simultaneously, you are genuinely national. If everything peaks in one window, your "national" product may effectively be regional, and a single well-placed region could serve the vast majority of your users at low latency.
Spotting the Underserved Metros
Once the map is drawn, the interesting question is where the gaps are. Look for metros with meaningful volume and poor latency — cities where p95 response times run two or three times your median. These are your candidates for edge caching, a new point of presence, or full regional deployment.
Prioritize by impact, not by count of complaints. A metro generating 8% of traffic with 400ms added latency may deserve attention before one generating 2% with 600ms. Multiply request volume by latency delta to get a rough "suffering score," and rank accordingly. It is not a perfect model, but it beats anecdotes from the loudest customer in your support inbox.
Timing the Expansion to Real Demand
There is a temptation to treat new regions as a growth milestone — a way of signaling ambition. Resist it. Every additional region carries real costs: data replication, operational complexity, and the subtle consistency questions that come with keeping state in multiple places.
A disciplined trigger looks like this: sustained traffic growth from an underserved geography over several months, latency that caching cannot fix, and a user base in that region that is growing faster than your overall baseline. When all three are true, expansion pays for itself. When only the first is true, a CDN upgrade is usually the cheaper and more reversible answer.
The Vanity Metric Trap
Finally, be honest about what is motivating the decision. "We have users in all fifty states" is a vanity metric. "Our p75 latency for the 60% of users in the eastern half of the country dropped from 310ms to 60ms after our second region" is an engineering result. The first makes a nice slide. The second makes a better product — and, incidentally, a stronger story in any future diligence conversation.
Your traffic map is not just an operations artifact. It is a record of where your product actually lives. Read it before you build for the country you imagine, rather than the one you have.
