Fly.io has inspired me for one-human scaled production. There's a ton you can do at 100% uptime... When the user is looking. Which is not often! You've got a ton of time for maintenance and reshuffling your infrastructure around. You've got tons of downtime if you do it in five minute intervals in the evening, and plenty of concurrency if you've got just one user. Serving from a file at a time is great. You can snapshot and replicate every five seconds and never miss more than one or two actions if you have to fail over if you're doing so for a single user's data, and for a single user.
That's a tradeoff you make if you're a user, and it's pretty worthwhile. There's something to play with
Can you link more concrete details about this? It kinda sounds like you're referring to the design of sharding databases by user, which i almost forgot about (relevant to me now, so i appreciate it). Though i'm super curious in how synchronizing data between users would work.. ie notifications, single producer multi consumer data, etc.
There's two classic pieces of wisdom that aren't so much wisdom anymore but pieces of the landscape:
The first is, don't write your own datastore, use a database. This is pretty much taken for granted today, but in the year 2000, there weren't a plethora of web frameworks. At the time, the unix filesystem didn't seem like such a bad interface to store things. Storing each user as their own file made sense. Simple enough. One (just one of several) way it runs into problems is when:
The other landscape concept - Run multiple copies of your app. This one is kinda controversial to this day, but it's core to the "Twelve Factor App", which was a somewhat prescient memo for it's day, if looking a little long in the tooth to my eye[1]. It's why people keep using Kubernetes. And it's correct advice - If you need to be running a ton of concurrency, you are better off scaling by process and keeping heavy-lifting logic out of your database. If you keep the database and application on separate hosts, you can scale to one big database server for writes, and many application servers and read-only database shards. This works really well for most crud and render-heavy applications you see on the web today; Social networks in particular absolutely thrive on this model.
This brings up another application architecture anomaly that's mostly disappeared - The "App in Database". There's a mildly successful model whereby almost all application logic lives in the database itself as stored procedures. You can do an entire app update as an atomic DDL commit! The database's permissions handle everything, and users just connect as users. In the old MVC model, the Database tables are M, the stored procedures C, and you write a V on top. I've encountered a few instances of this paradigm, most notably an accounting software that worked pretty great.
Fly suggests throwing all of this out the window. Most applications don't need a lot of write-scaling. You don't even need read concurrency. Run a single shard, make that shard fast, performant, and replicable - When it's shut down, you can make many copies of it, and resume from any of them. When a new one starts up, it becomes the primary, all of the others are marked as stale, and you resume making copies. If you're using Litestream like Fly does, this makes for a drop-dead simple app environment. Alternatives, like I'm using at home, are ZFS replication - SQLite is snapshot safe, so I just snapshot frequently, replicate those snapshots frequently, and reverse direction when necessary.
That's a tradeoff you make if you're a user, and it's pretty worthwhile. There's something to play with