Building at the Edge: How Hummingbird Achieves Sub-100ms Latency

When we set out to build Hummingbird, we had a clear goal: create the fastest geolocation API possible. Here’s how we achieved sub-100ms median latency.

The Traditional Approach (And Why It’s Slow)

Most geolocation APIs follow a familiar pattern:

1. Request hits a load balancer
2. Routes to a central data center
3. Queries a database
4. Returns the response

The problem? Geography. If your server is in Virginia and your user is in Singapore, you’re looking at 200+ milliseconds just for the round trip.

The Edge-First Architecture

Hummingbird takes a different approach. Instead of running from central data centers, we run on Cloudflare Workers at 300+ edge locations worldwide.

How It Works

1. Request arrives at the nearest edge - Cloudflare routes to the closest PoP automatically
2. Data is already there - Our geolocation database is replicated to every edge location
3. Response returns immediately - No cross-continent hops needed

The Results

• Median latency: Under 100ms globally
• P95 latency: Under 150ms
• P99 latency: Under 200ms

Compare this to traditional APIs that often have 200-500ms response times.

The Database Challenge

The tricky part of edge computing is data. Traditional databases don’t work well at the edge - you can’t replicate PostgreSQL to 300 locations.

We solved this by:

1. Pre-processing - Our IP geolocation data is optimized at build time
2. Binary search - Lookups are O(log n), extremely fast
3. Smart caching - Frequently accessed data stays hot

What We Learned

Building for the edge requires rethinking assumptions:

• Stateless is essential - Each request is independent
• Data size matters - Every byte gets replicated
• Cold starts are real - Optimize initialization

Try It Yourself

Experience the speed difference. Sign up for free and make your first request in under a minute.

---

Want to learn more about our architecture? Have questions? Get in touch.