Other than batch jobs, I can't think of a problem that can be solved these days that doesn't also require high availability - at the very least they require a warm standby.

I live in the ERP-adjacent world, and the vast majority don't have any of that, never have, and I pray most don't.

P.D: the business world is the one that needs AND tries everything, and most attempt to implement something is much worse than the simpler previous thing.

For most that I know and most I bet (even without knowing) add "high availability" or "warm standby" WILL CERTAINLY lead to worse availability.

In fact, the best setup for most people, and consider things from today (that you will see, not that different from mainframe days!):

- Single server on a *nix LTS/immutable distro with just the RDBMS + App backend, on decent hardware. Fast, lots of ram or whatever optional

- A true reliable backup system

- A decent network setup, ideally a VPN one for connect everybody, with good firewall, SSL and that is

More complex than this and is 90% certain is much worse, other 8% until the dude that do it and care leaves.

I dunno, it often matters a lot less than you think when something goes down. And distributed systems have a knack for going down in a much less predictable way, it's not going to automatically make your system more reliable.

(modern server hardware and operating systems are also surprisingly reliable nowadays, which makes it harder to reach breakeven with a distributed design)

So take 16 independent computers and have them each solve the problem separately. You'd still be saving 80% compared to the paper's benchmarks. It wasn't close.

McSherry does a lot of interesting work on making monotonic/incremental distributed systems efficient (e.g. Differential and Timely Dataflow). Those kinds of systems scale much more linearly.

Sometimes your entire business is just a laptop with a python dictionary and a backup power supply