Why does GSLB suck?

Now, before I start to fan the flames, let me start with the usual caveat; GSLB doesn't ALWAYS suck — just more often than you'd think...

Multi-site GSLB is simple, but not easy

There's normally two things customers ask for when they approach us saying they want GSLB:

1. Active-Passive failover between two internet sites (for Disaster Recovery and High Availability).
2. Active-Active load balancing between two or more geographically dispersed sites i.e. Europe and USA (for Performance and High Availability).

Sounds simple enough, doesn't it?

And It's exactly the kind of thing that CloudFlare is awesome at...

But let's briefly step back to what we should have done first, which is make sure our primary site (and all our sites for that matter) are as indestructible as possible.

Have you already got the following?

• 2 x Internet feeds
• 2 x Switch fabrics
• 2 x Firewalls
• 2 x Load balancers (no persistence/sticky here please, we want high availability after all)
• 3+ Web servers
• 2+ Database servers (gee, I wonder if we could put the persistence here?)

Done that?

No?

Then go and do that first before you think about GSLB!!

Assuming you've done that already, then great, by all means let's explore GSLB...

What people think GSLB is and why you’re probably doing it wrong

A lot of people think that GSLB is all about using the closest data center to your location so that you get low latency for remote workers.

Yes, that’s important and we definitely recommend you use something like Cloudflare for that, and while you’re at it make use of their excellent CDN features for static content.

But when it comes to true multi-site applications like AI & Object Storage. Then saving a few milliseconds of latency is not important. What’s important is getting 100X the performance for local applications and storage, by ensuring local traffic in the data center stays local. And saving 10X bandwidth costs on data center WAN connections for replication of data.

GSLB isn’t about geography. It’s about locality, health, and app awareness. So if your load balancer doesn’t know what your application is doing, it’s not smart load balancing — it’s just hoping.

Cloudflare’s global network is built for broad website content delivery — not high performance applications for AI and storage infrastructure.

Luckily, Smart GSLB works seamlessly with Cloudflare so we recommend that you use both.

How can you get GSLB right and make sure it doesn’t suck?

Smart GSLB uses real-time data to intelligently route traffic. Because it understands where your applications and users are, and how your infrastructure is configured using site-specific subnet topology.

This is crucial for critical applications using object storage, such as expensive AI infrastructure where bandwidth constraints cost a huge amount of wasted time and money. Or for critical healthcare systems, where data sovereignty and uptime are non-negotiable.

And when it all goes wrong our GSLB ensures quick multi-site failover, meaning no manual DNS updates and zero downtime for your critical applications.

By combining real-time health checks, application awareness, and true locality-based logic, Smart GSLB intelligently routes every request to the right place on the first attempt, making sure it’s fast, secure, and compliant.

But the most important thing is not the technology — it’s the people who help you get it done right.

Don't get me wrong, Cloudflare is awesome...

Cloudflare does an amazing job at what people think* they want from GSLB, but it sucks in comparison to on-site GSLB when it comes to real world performance.

When should you use a smart local GSLB instead of Cloudflare?

The primary reason to use a smart GSLB is for multi-site resilience; when you need site failover or more importantly locality based routing i.e. use local site first to save on bandwidth costs and latency.

The secondary reason to use smart GSLB is when you need seriously high performance load balancing (for example large multi-site object storage systems).

With both of these scenarios, you are worried about writing and replicating your application data, as well as just read performance.

However, If your users as mostly just reading static data...

Then go ahead an use Cloudflare, because it sure doesn't suck at that!