How we built JSR
In this technical retrospective (2024), @vladev shares practical architectural lessons learned from running, scaling, or migrating production software under lean constraints.
HN engineers debated the tradeoffs between cloud convenience and raw server economics, database indexing strategies, and resisting premature architectural complexity.
I'm not sure what 100% uptime is supposed to mean. Zero downtime, thats like saying zero bugs - it's not going to happen. Even 99.9999% uptime would be realistic, but 100% is not happening. There are factors out of your control that you cant guarantee will not even be down 1ms per year.
How do you manage 100% uptime when your db is only going to be 99.9%? The latter is almost easy, the former, even if we assume 99.99999%, really really hard.
Just silly and may show that there are some unrealistic assumptions, maybe? Or maybe the team doesn't know much about reliability -- also concerning.
Just target six nines and be done with it, or something.
In may of last year, NPM was down to 99.8 for the month.
So how do we make serving modules reliable? We defer the entire problem to Google Cloud. The same infrastructure that serves google.com and YouTube is used to host modules on JSR. None of our custom code sits in this hot path
I work at Google and even I do this. Services like the storage backing GCS are incredibly reliable and have teams of SREs supporting them, so I offload as much as possible to services that have more dedicated support than I'm able to provide.
Reading a file takes a couple hundred nanoseconds on a modern SSD.
According to "Latency Numbers Every Programmer Should Know (2020)" [1] reading even a single page from a modern SSD takes over 10 microseconds.
[1] https://colin-scott.github.io/personal_website/research/interactive_latency.html ↗
We use the excellent sqlx Rust package to handle migrations.
The JSR API server is written in Rust, using the Hyper HTTP server. It communicates with the Postgres database via the sqlx Rust crate.
Looks like most of the backend is written in Rust. Must be a bummer working on a JS runtime, and not being able to test it out at such a scale.
Just a small point but google.com and YouTube do not run on the same infra as what you see on GCP, especially if you use GKE etc...
It's trivial to see because when GCP is down somehow Google and Gmail keep working.
Interesting that they use Rust for most things, rather than Deno. I would've expected more dog-fooding on their part.