Sponsored by
Hello friends!
Welcome to this week’s Sloth Bytes. I hope you had an amazing week.
Learn AI in 5 minutes a day
This is the easiest way for a busy person wanting to learn AI in as little time as possible:
Sign up for The Rundown AI newsletter
They send you 5-minute email updates on the latest AI news and how to use it
You learn how to become 2x more productive by leveraging AI
🦥 Geohashing: How Location Search Avoids Checking Everyone
You open a location-based app and it finds nearby drivers, restaurants, or stores within seconds. But a global service might have millions of locations. How do you avoid calculating an exact distance to every single one?
One classic answer is geohashing: map latitude/longitude into hierarchical grid cells so you can narrow the candidate set before doing more expensive distance checks.
It’s one of several spatial-indexing approaches. Real systems may use geohashes, R-trees, quadtrees, S2/H3-style cells, database-native geospatial indexes, or combinations of these depending on the workload.
The Problem
Imagine you’re building a ride or delivery app. You might have:
millions of active locations globally
a user asking for results near one coordinate
a radius such as 2 miles or 5 kilometers
You could do a simple approach like this:
nearby_drivers = []
#loop through all 5 million drivers
for driver in all_5_million_drivers:
if distance(user, driver) < 2:
nearby_drivers.append(driver)But that’s not a good idea…
That's 5 million distance calculations. Every. Single. Request.
And that’s not including the time it took to fetch the data of those 5 million drivers.
Your servers are now on fire and your users just missed whatever appointment they had waiting for a driver.
The Solution: World as a Grid
Classic geohash encodes a latitude/longitude pair into a short base32 string representing a rectangular cell:
San Francisco: (37.7749, -122.4194) → "9q8yyk"
Why is this effective?
Longer shared prefixes generally mean points are in the same increasingly precise grid region. But there’s an important catch: two physically nearby points can have very different-looking geohashes if they sit on opposite sides of a cell boundary.
Uber HQ: (37.7749, -122.4194) → "9q8yyk"
Starbucks next door: (37.7751, -122.4190) → "9q8yym" (similar)
Tokyo: (35.6762, 139.6503) → "xn774c" (completely different!)
Each additional character increases the grid resolution by subdividing the represented region further.
More characters = more precision.
A geohash prefix can be indexed efficiently, which makes it useful for narrowing the search to one or more candidate cells:
-- Simplified candidate lookup, not a complete radius query
SELECT *
FROM drivers
WHERE geohash LIKE '9q8yy%';But this is only the candidate-generation step. A single prefix cell is a rectangle, not a circle around the user, and nearby results may live in neighboring cells.
A more realistic proximity query looks like:
1. Encode the user’s location at a useful geohash precision.
2. Query that cell plus the neighboring cells that could overlap the search radius.
3. Run an exact geographic-distance calculation on the much smaller candidate set.
4. Keep only results whose true distance is within the requested radius.That is the actual win: the spatial index cheaply shrinks millions of possible points to a manageable candidate set, and then exact distance math finishes the job.
Who Uses Ideas Like This?
Databases/search systems: geospatial indexes narrow location queries before exact filtering
Ride-sharing and delivery systems: hierarchical spatial cells help bucket demand, supply, orders, and other location events
Nearby search: restaurants, stores, people, devices, and map features can be grouped spatially before ranking/filtering
Uber specifically: Uber publicly documents its own H3 hierarchical hexagonal grid for marketplace geospatial analysis and indexing. H3 solves a similar “bucket the world into searchable cells” problem, but it is not classic geohash.
If you’re interested in learning more check out this article:
If you want to keep learning
How Google Maps finds the fastest route — another look at location systems, this time using graphs, Dijkstra, A*, and routing optimizations.
5 system design resources — go deeper on the architecture patterns behind large-scale location, database, and distributed systems.
Big O notation explained — understand why narrowing millions of locations before doing distance calculations changes the performance so dramatically.
Thanks for the feedback! I’ll do a game dev topic next week 😁
Thanks to everyone who submitted!
andregarcia0412, lighto782, xanerin, GabrielDornelas, That1neGuy1, dganesh05, Sorbojit1, AspenTheRoyal, lidoreuven, JamesHarryT, RelyingEarth87, SabhyaAggarwal, mau-estradiote, soymehdi
This solution has a special place in my heart. Shoutout Miles!
Amazing solution
Birthday Cake Candles
You are in charge of the cake for a child's birthday. It will have one candle for each year of their total age. They will only be able to blow out the tallest of the candles.
Your task is to count how many candles are the tallest.
Examples
birthdayCakeCandles([4,4,1,3])
output = 2
// The tallest candles are 4. There are 2 candles with this height, so the function should return 2.
birthdayCakeCandles([1, 1, 1, 1])
output = 4
// All candles are the same height, so all are the tallest.
birthdayCakeCandles([])
output = 0
// No candles, so nothing to blow out.How To Submit Answers
Reply with
A link to your solution (github, twitter, personal blog, portfolio, replit, etc)
or if you’re on the web version leave a comment!
If you want to be mentioned here, I’d prefer if you sent a GitHub link or Replit!
That’s all from me!
Have a great week, be safe, make good choices, and have fun coding.
If I made a mistake or you have any questions, feel free to comment below or reply to the email!
See you all next week.
What'd you think of today's email?
Want to advertise in Sloth Bytes?
If your company is interested in reaching an audience of developers and programming enthusiasts, you may want to advertise with us here.
