Remix.run Logo
▲ cyberax a day ago

I think we'll see a reduction in complexity and an increase in transparency, rather than just on-prem.

One medium-sized server can now easily serve the entire banking system of a large country. So you don't need clusters of servers with careful tradeoffs between consistency and availability because of the CAP theorem.

Just get a big honking host, slap Postres on it, and run your application server in a VM on the same host. For backup, export the WAL logs from Postgres onto your favorite off-site blob storage. UI for it? There's Pigsty.

It still makes sense to host this in a cloud provider, just because you probably don't want to deal with actual hardware. And maybe get a second standby server for redundancy.

That's it.

You'll need a bunch of external dependencies for email, 2FA, observability, LLMs, and so on. But they should all be outgoing dependencies that should not allow access back into your system.

▲mosura a day ago | parent [-]

Real loads are too spiky for that.

▲cyberax a day ago | parent [-]

A PostgreSQL server on an NVMe can handle several _million_ simple requests per second. This is bonkers.

Do you think you can hit these load levels? For compute, a 64-core CPU can saturate a 10G network with simple template rendering. If the code is written in something reasonably fast (Go, Rust, Java).

Of course, if you're on a scale of Amazon or Stripe, you'll need more than that.

▲mosura 20 hours ago | parent [-]

This is how we spot someone that has never done transaction processing in a consumer facing business. You are focused on completely the wrong dimensions.

Postgres fanboys are insufferable.

▲lukewilson02 17 hours ago | parent [-]

You sound insufferable. Educate us, wise guy.