4 ms·

Exactly this. The only thing unmentioned, but that you should be aware of, is the effort to deploy this stack from scratch. You can assume the DB survives, or

Exactly this. The only thing unmentioned, but that you should be aware of, is the effort to deploy this stack from scratch. You can assume the DB survives, or doesn't, but the ability to go from zero to a running deployment from a recent restore is probably the only thing you need to really worry about. If you can get that to be less than hour, or ideally a few minutes, then you're golden. Don't be afraid to add CDN/Caching when its appropriate. You can always buy a beefier instance, or a dedicated box. Deal with the scale later when its truely needed. Give yourself permission, or plan to hire a team, to handle the scale issues later.

happytiger 3y ago
This is the most important advice for an early stage startup trying to scale. Being able to automatically build production from a recent snapshot is a profoundly important point. When we bootstrapped on the cheap we would always maintain a production infrastructure at one company and a test infrastructure at another with a relatively low TTL dns infrastructure hosted at a third party like dnsmadeeasy. Backups would be pushed to the second site. We then would “build our demo” from the backup data (stripping PII at runtime). But the demo served as a second clone production infrastructure. If the primary went down, it was always a quick restore and scale up at the secondary location with recent backups! Worked really well, but you needed to make sure it was automated or it would blow up. Definitely cheap and works like a charm. I’m sure that’s over complicated for a lot of people, but it’s really just a few scripts and a couple of days to set up, and you can be up and rolling with a working system in the time it takes to change DNS.