We eventually ended up using Cloudflare CDN to deliver translation files to games, while the web application handled editing, managing projects, and publishing updates.

It made sense for what we were doing. Translation files don't change every few seconds, and there wasn't much reason for every game client to keep requesting the same files from our main server.

We also had synchronization and cache purging in place, so updated translations could be published without waiting for a fixed cache expiration.

Everything seemed fine.

Then Cloudflare actually went down.

This wasn't a test

We hadn't planned a failure simulation or anything like that. Cloudflare was simply unavailable for a while.

And that's when we started thinking more seriously about how much our system depended on it.

If Cloudflare is down, our website might be unavailable too. Developers may not be able to log in, edit translations, or manage their projects.

That's annoying, obviously.

But there's a difference between a developer not being able to update a translation for an hour and a player not being able to load the translations that already exist.

A player doesn't care whether our admin dashboard is working.

They just want to launch their game, open the menu, and play.

So we started asking ourselves: why should an outage affecting the management side also affect translation delivery?

That question is what pushed us toward an independent fallback server.

Keeping a copy outside Cloudflare

The idea wasn't to replace Cloudflare. We still wanted it to handle normal translation delivery.

But we needed another place where the published translations would be available.

So we added a separate fallback server, outside Cloudflare, with its own copy of the translation files.

Under normal conditions, the game can load translations through the CDN.

If that route isn't available, it can try the fallback source instead.

The fallback doesn't need the whole translation management system. It doesn't need an editor, project settings, or all the other features of VeluTranslate.

Its job is much simpler: have a copy of the files ready when the primary delivery path isn't working.

We liked that separation. Even if the website used for managing translations is temporarily unavailable, there can still be another way for a game to retrieve its existing language files.

Of course, this doesn't mean every possible outage is solved. The fallback server can fail too, and clients still need a working connection to reach it.

But we no longer have to rely entirely on one delivery provider.

There's a trade-off: the fallback may be slightly behind

Here's one detail we had to accept.

Our fallback server isn't synchronized with every translation change in real time.

It keeps its own copy, updated through a separate synchronization process.

In normal operation, that copy might be around 5–10 minutes behind, depending on when the latest sync completed.

Let's say a developer fixes a translation and publishes the update.

The new version reaches the primary delivery system, but the fallback hasn't completed its next synchronization yet.

If Cloudflare becomes unavailable at that exact moment, a player might receive the previous version of that string.

And for us, that's usually fine.

Would we prefer the latest translation? Sure.

But if the choice is between a slightly older translation and not being able to retrieve one at all, we'd rather have the older one.

It's worth noting that 5–10 minutes isn't a guaranteed maximum delay. If synchronization stops working or an outage lasts longer, the fallback copy could become older.

That's something we have to account for.

Still, for the kind of content we're delivering, this trade-off makes sense to us.

What the setup looks like now

We've ended up with a few separate responsibilities.

The web application is where developers manage projects, languages, and translations.

The synchronization process handles publishing translation updates.

Cloudflare CDN is the primary way games retrieve published language files.

The fallback server keeps a separate copy outside Cloudflare, ready to serve those files if the primary route isn't available.

It isn't an especially complicated idea when written down like that.

Getting there took a little longer, though. :)

And there are still plenty of details behind it, especially around keeping the copies synchronized and making sure clients behave correctly when something fails.

For now, the important part is that our translation management interface and our translation delivery paths don't all have to share exactly the same availability.

And what if the player has no internet at all?

The fallback server helps when Cloudflare is unavailable but the player still has internet access.

It doesn't help much if the player is completely offline.

That's where local translations come in.

Our Unreal Engine plugin can keep previously downloaded translations on the player's device. Once they're available locally, the game can continue using them without connecting to a server.

Developers can also bundle language JSON files directly into their game build.

We actually recommend doing that when possible.

It means the game already has translations available on its very first launch, even if the player has never connected to the internet.

If the files aren't bundled, the plugin can download and store them during a successful online session.

For other integrations using our Runtime API, developers handle local caching and offline behavior in their own applications.

So we now think about translation availability in a few different situations: normal online delivery, a problem with the primary CDN, and a player who has no connection at all.

They need slightly different solutions.

What we took away from the outage

The funny thing is, we didn't add this fallback because we were sitting around planning for every possible disaster.

A real outage happened, and it made us question something we'd previously been comfortable with.

Until then, we'd spent a lot of time thinking about how to publish translations efficiently and how to push updates without rebuilding a game.

We hadn't paid quite as much attention to what would happen if the service delivering those files became unavailable.

That experience changed how we looked at it.

We realized that being unable to edit translations and being unable to use existing translations shouldn't automatically be the same problem.

The website might be temporarily unreachable. A developer might have to wait before updating a string.

But the game should still have a reasonable chance of loading the language files it needs.

We're not claiming the system is immune to outages. It isn't.

We simply removed one dependency that became much more obvious when it failed in real life.

And sometimes that's how these things get built. You solve one problem, something unexpected happens, and suddenly you've got another piece of infrastructure to maintain. :D

A little about VeluTranslate

This fallback setup is now part of VeluTranslate, the localization platform we're building for games and applications.

Alongside translation delivery, it provides project and language management, an Unreal Engine plugin, and a Runtime API for other engines and custom integrations.

We're still developing it, and we'd like to see how it works outside our own projects.

That's why we've opened the VeluTranslate Pilot Program for developers who want to try it and give us feedback.

Selected projects can get 60 days of free access to the platform. AI translation is optional, and AI credits are billed separately if used.

If you're interested, you can find more details here:

VeluTranslate – Pilot Program

How would you handle this?

I'm curious how other developers deal with similar situations.

If your game or application loads content from an external service, what happens when that service goes down?

Do you keep a local copy, use a second server, or just wait for the primary service to come back?

And for something like game translations, would you rather have the latest version at all times, or a slightly older version that's still available during an outage?

Would be interesting to hear how others approach it. We might learn something useful from your setups too.