As a thought exercise, I thought about how I would architect a web application as a 1 man show with a relatively small amount of users.
I tried to optimize for cost and very little devops at all. I still mull about it but so far, here is what my architecture would look like.
- no servers to manage
- static website hosted on CDN, and even dynamic user-specific pages would be built statically every 8 minutes
- all writes go to an SQS queue
- every 8 minutes, a lambda is spun up to batch read the SQS queue and all writes go through a single writer process that writes to a SQLite file on EFS
- every 8 minutes, a new static version of the site is built using the above hopefully updated SQLite file
The one thing I hate about this is that I can't in good conscious say to the user that their write request succeeded b/c no state has actually changed on the backend yet. but I might be okay with this tradeoff and just simply showing only them their most recent write.
The other tradeoff is when things go wrong, it'll probably go terribly wrong.
I tried to optimize for cost and very little devops at all. I still mull about it but so far, here is what my architecture would look like.
- no servers to manage - static website hosted on CDN, and even dynamic user-specific pages would be built statically every 8 minutes - all writes go to an SQS queue - every 8 minutes, a lambda is spun up to batch read the SQS queue and all writes go through a single writer process that writes to a SQLite file on EFS - every 8 minutes, a new static version of the site is built using the above hopefully updated SQLite file
The one thing I hate about this is that I can't in good conscious say to the user that their write request succeeded b/c no state has actually changed on the backend yet. but I might be okay with this tradeoff and just simply showing only them their most recent write.
The other tradeoff is when things go wrong, it'll probably go terribly wrong.