How “Locate Me” Works — The Full Stack Behind Every Tap

From GPS satellites to your Uber driver’s dot moving on screen

You open Uber, tap “Use my current location”, and within a second the pin drops exactly on your building. You didn’t type anything. The app just knew.

How?

This article explains the full journey — from the moment you tap, to the moment the driver’s dot starts moving on your screen. No jargon. And where it matters for interviews, we’ll call out the key ideas.

The Big Idea First

Your phone doesn’t have a magical “location chip.” It listens to signals from three different sources around it, makes its best guess about where you are, and hands that guess to the app. The app then sends that guess to a company’s servers, which figure out which driver is nearest and push updates back to your screen in real time.

That’s the whole story. Let’s walk through each part.

Step 1 — Three Ways Your Phone Figures Out Where You Are

Your phone uses whichever of these three signals is available, and often blends all three.

GPS — the most accurate, but slow and power-hungry

GPS satellites orbit the Earth about 20,000 km up. Your phone’s receiver listens to signals from at least three of them, measures how long each signal took to arrive (travelling at the speed of light), and uses the geometry of those distances to pinpoint where on Earth you must be standing.

Accuracy: about 3–15 metres outdoors. This is why Google Maps can put you on the right side of the road.

The catch: GPS struggles indoors. The signals are blocked by concrete and steel. And it drains your battery faster than WiFi or cell towers.

WiFi — surprisingly useful, even when you’re not connected

Over the years, Google and Apple have quietly built a database of nearly every WiFi router in the world and its physical location. When your phone spots nearby routers — even without connecting to them — it looks them up and gets a location estimate.

Accuracy: roughly 10–20 metres. Not as sharp as GPS, but works well indoors and uses very little battery.

Cell towers — the rough fallback

When GPS is blocked and there’s no WiFi, your phone falls back to the mobile network. By measuring signal strength from at least three towers and doing some geometry, it estimates where you are.

Accuracy: 500 metres to 1.5 km. Good enough to know you’re in Connaught Place, not precise enough to know which restaurant you’re standing outside.

Interview angle: If asked “what happens when GPS fails?”, this cascade — GPS → WiFi → cell towers — is the answer. It’s called graceful degradation.

Step 2 — Your Phone’s OS Does the Hard Work Silently

Here’s something most people don’t realise: your app never talks to the GPS hardware directly.

Android and iOS sit in the middle. When Uber says “give me the user’s location,” the operating system checks all three sources, picks the best available signal (or blends them), and hands back a single clean result — one latitude, one longitude, and an accuracy estimate.

On Android this is called the Fused Location Provider. On iOS it’s called Core Location. Both do the same job: hide the messy signal-blending from the app and serve one reliable answer.

Interview angle: This abstraction is intentional. It means apps don’t need to implement their own fallback logic. It also means Apple and Google control how precise the location apps can get — they can limit accuracy at the OS level.

Step 3 — You Grant (or Deny) Permission

Before any of this reaches the app, there’s a gate: you.

On iOS you can choose:

• Always — the app can see your location even in the background
• While using the app — only when the app is open
• Approximate — give the app a rough area, not a precise point
• Never — the app gets nothing

On Android the options are similar, with the addition of “only this time.”

Uber, by default, asks for “While using the app” — precise location, but only during your session. If you deny location entirely, you can still book a ride — you just have to type your pickup address manually.

Interview angle: Permission tiers are a privacy design decision. Apps that ask for “Always” face more user friction and rejection. Most consumer apps default to “While using” to maximise acceptance rates.

Step 4 — What Data Actually Leaves Your Phone

This is where the data size question becomes interesting.

Your latitude and longitude are each stored as a 64-bit decimal number (called a double). Two of them = 16 bytes of raw data. That’s the size of four words in a text message.

But in a real app, the location update also carries a few extra fields: how accurate the reading is, your speed, your compass direction, and a timestamp. Wrapped in the standard JSON format apps use, one location update is about 150 to 300 bytes — roughly the size of a tweet.

Here’s what that looks like:

{
  "lat": 28.6148,
  "lng": 77.2090,
  "accuracy": 12,
  "speed": 8.2,
  "timestamp": 1718000432
}

That’s it. Small. But multiply it by frequency and scale, and it becomes enormous.

Step 5 — How Often Does the App Send Your Location?

Apps like Uber send your location to their servers roughly every 4 seconds while a trip is active.

That means:

At that scale, you can’t store each ping directly into a database — the database would collapse. This is why companies use a message queue (like Kafka) to absorb the flood first. Think of it like a post office receiving boxes faster than it can sort them — so it queues them up and processes them steadily.

Interview angle: This is a classic scale-vs-storage trade-off question. The answer is always: separate ingestion from processing using a queue.

Step 6 — What Happens on the Server Side

Three things happen almost simultaneously when your driver’s location ping arrives:

1. It goes into a message queue (Kafka) Every ping is stored as an event in a log. Nothing is lost. The rest of the system reads from this log at its own pace.

2. An ETA engine recalculates your arrival time Your 8-minute ETA isn’t fixed — it updates every few seconds based on the driver’s actual movement, traffic, and the road network. The server runs a routing algorithm on every ping.

3. A location store (Redis) keeps the latest position Redis is an in-memory database — very fast. It stores every driver’s current coordinates and can answer “find all drivers within 2 km of this point” in milliseconds. This is how the app shows nearby available cars almost instantly.

Interview angle: This three-component pattern — queue for ingest, processor for computation, in-memory store for fast lookup — comes up in almost every real-time location or tracking system design question.

Step 7 — How the Driver Dot Moves on Your Screen

The final step: getting the updated location from the server back to your screen without you doing anything.

Regular apps ask the server “any updates?” every few seconds (called polling). That’s slow and wasteful.

Real-time apps like Uber and Swiggy use WebSockets — a persistent, open connection between your app and the server. The moment the server has a new location, it pushes it to your phone instantly. Your app moves the driver’s dot on the map. No refresh. No tap. It just moves.

Interview angle: When asked “how do you show real-time updates in a mobile app?” — WebSockets is the answer for true push behaviour. Long polling and SSE (Server-Sent Events) are acceptable alternatives worth knowing.

The Nitty-Gritties — Questions That Come Up a Lot

Why does GPS stop working inside a mall or metro station? Satellite signals can’t pass through thick concrete and steel. The phone falls back to WiFi and cell towers, which is why your blue dot on Maps freezes or jumps when you go underground.

Does denying location permission actually protect you? Partially. Your own location sharing stops. But if you’re in an Uber, the driver’s location is still tracked — and that data, linked to your booking, still reveals your journey.

What’s the difference between “precise” and “approximate” location? Approximate gives the app your general neighbourhood — accurate to a few kilometres. Precise gives it your exact position to within metres. Weather apps only need approximate. Cab apps need precise.

Is location data sensitive? Yes — under privacy laws like GDPR, location data is treated as personal data because a pattern of location points can reveal your home, your workplace, your hospital visits, and your daily routine — even without your name attached.

How Much Data Does One Location Ping Carry?

Every 4 seconds, a driver app sends a packet like this to the backend:

json

{
  "driver_id": "550e8400-e29b-41d4-a716-446655440000",
  "lat": 28.614876,
  "lng": 77.209021,
  "accuracy": 12.4,
  "speed": 8.2,
  "bearing": 245,
  "timestamp": 1718000432000
}

Small packet. Big implications at scale. Let’s break it down field by field.

Lat and Lng — the core of the packet

Latitude is north-south (-90 to +90). Longitude is east-west (-180 to +180).

For ride-sharing, 6 decimal places is the right call — lane-level precision, no more needed.

Type: double (8 bytes). Never float — float only gives 7 significant digits, which rounds a 9-digit coordinate and introduces ~1 metre of error per ping.

WorldLatLngTotalMemory8 bytes8 bytes16 bytesJSON9 bytes9 bytes18 bytes

Remaining fields

Total — memory vs wire

The key names ("accuracy", "timestamp") add 7–11 characters of overhead each — that is where JSON inflates. High-throughput systems switch to protobuf to strip key names and stay close to binary size, shrinking the packet 3–4×.

At 1 million active drivers pinging every 4 seconds, that difference is ~3 TB less data per day.

The Full Journey in One Line

GPS or WiFi or towers → phone OS blends them → you grant permission → app sends 150 bytes every 4 seconds → Kafka queue → ETA engine + Redis → WebSocket → dot moves on your screen.

That’s “Locate Me” — the full stack, in plain English.

Enjoyed this? Follow me at @puneet_kumar_agarwal for more practitioner-level distributed systems writing.