Why we're moving off Cloudflare Durable Objects | Hacker News Reader

Why we're moving off Cloudflare Durable Objects

usewire.io

59 pointsjitpal13 comments

> What we built > Each organization gets one host process (Bun) on Fly Machines for all its containers.

Well that is an instant nope from me. Fly.io's uptime/availability isn't something I trust and I am not alone. Part of what makes cloudflare durable objects great is the sheer availability and consistency at a true global scale

I'm largely there with you... Cloudflare Durable Objects feel like the best means to implement a sequential number generator. I think a lot about mail and message systems... part of why I'd been really excited to see what CF had started with in terms of mail systems support. They've got really great natural privatives for a first class, modern mail and message systems. In practice, handling updates to threads or simpler value assignment/alias DO is just such a great fit.

For reference, part of where the thought exercises are for is in terms of replicating what might have been a traditional BBS message net, but a massive hub for such activity on Cloudflare hosting. Some pieces burrowed from FTN (Fidonet technology) but some rethinking in terms of more modern capabilities in practice.

From one hip fly by night set of components to another

Totally fair, and I won't pretend matching Cloudflare on durability is easy. It's the hardest part of this, and the main reason the new infra is opt-in beta rather than the default. We won't move anyone off DO by default until we're confident the durability story holds.

On availability, Cloudflare is the gold standard, no argument. We get a lot more control with this setup, including the failure path. With a DO you're at the mercy of the platform's placement and migration. With ours, when a host or region goes sideways, we can deliberately reroute and rehydrate the org elsewhere instead of waiting on the platform. That doesn't beat CF's raw availability and uptime, but it's a recovery lever we didn't have before.

It also unlocks something DO structurally couldn't: running the whole stack in a customer's own cloud (BYOC). For the regulated teams we're building for, that requirement alone was worth the trade.

Please don't generate comments here, it's against the rules.

Why do all this work and then let an ai write the blog post.

Fair feedback.

Worth calling out

Exactly my thoughts.

The thought of moving back to Fly after CF is completely absurd to me, each to their own. May your downtime be minimal...

Took me a bit to understand what Wire does, but then it clicked. we’ve built something similar at a smaller scale inside R2, though right now it’s only for .md files.

I can see this becoming much more useful once the docs get heavier: large PDFs, XLSX files, images, etc. At that point you probably need embeddings, reranking etc. But I think agents are smart enough to write scripts to retrieve what they want if we run them on a sandbox(which we are trying to do currently). bookmarking this for now.

Good write-up though!

The objects are durable, but not endurable.

Durability is not the problem, but because the state lives somewhere you structurally can't relocate. That constraint never shows up in a benchmark, it shows up in an enterprise procurement call.

Reply on news.ycombinator.com