Multi node systems tend to have more failure modes, so fail more often, high availability is not free.

If you replicate data between two nodes (that are note async backups). You have to maintain strong data consistency. So writes to the database are considered successful only if the data is written to both nodes. If either node became unavailable you'd be unable to write anything without sacrificing consistency, reducing our overall availability rather than improving it. Also increasing latency.

This is why the whole multi node HA push by the industry is so laughable. A lot of time it makes systems more fragile.

They also don't always support window sizes above 8MB which means levels above 19 can fail to decompress (if they use the more than 8MB of window).

A shame browsers don't support concatenating zstd frames (which zstd does support). Then you wouldn't need to decompress, just serve zstd straight to the browsers after concatenating the frames you care about.

Hell, for a lot of projects you don't even need to get that fancy. Run a single server with an embedde database, running Go or Java and you're good to go.

With a fast backend ~1-5ms response times (not even that fast). Streaming compression over something like SSE to keep your response sub 1kb packet (roughly an ethernet MTU).

With a push based model, pushing data to a user is half their RTT latency. They will only experience their full RTT on actions they trigger.

Now the network to you is distance to the server (not your rail/nextjs backend taking 400ms). Things like 4G and 3G are fine. The real problem is when you have such bad signal you effectively have no down or up.

[1] - https://andersmurphy.com/2025/12/02/100000-tps-over-a-billio...

For everyone adding value with LLMs there will be way more destroying value. If you roll a critical failure a mediocre LLM enhanced VP convinces the org to sail aggressively in the wrong direction.

But, for me it's not so much that it doesn't match my view. I'm honestly mixed on the whole thing (I am probably most concerned about the finances). It's more that the articles they write seem to align with the eb and flow of anthropics media tempo. This week it's FOMO, next week it's panacea, hack all the things week, followed by mild financial concerns with a but it will be fine tacked at the end. The articles tend to lack concreteness too. Maybe, it's just what reading The Economist is like when it's a domain you actually understand and follow closely?

Honestly, though I could probably say the same for a lot of publications these days.

Longtime subscriber. Pretty disappointed in how biased their coverage is.

The most critical piece they have put out on AI is oh no it's so powerful it's hacking everything. It's like being in a job interview and saying your biggest weakness is you work too hard.

What's worked for me is I block any client that don't support brotli compression and http2. Seems to work well enough for stopping scrapers.

Basically, if your html fat morph frames are 65kb uncompressed and you make a small change like checkbox it will send 13bytes so that's 5000:1. Caveat is as long as your compression context window is big enough.

Once you want realtime/collaborative app SSE + morph lets you do that easily. Add streaming compression and this approach is suddenly crazy bandwidth efficient.

For people coming from react this gives you v = f(state) over the wire.

Lastly signals handle the edge cases where an out of bound morph would nuke your ephemeral client side state (mostly text input).

You can do this in htmx but you are fighting the design the whole way. Turbo is a bit better but doesn't have signals.

[1] https://dev.37signals.com/a-happier-happy-path-in-turbo-with...