> Even now, one of our most trafficked services today still has a single node.js instance serving 60K requests per hour (topic for another blog post).<p>So 60k per hour is 1k per minute is 16 per second. That is... not that much? Certainly not really blog post material.
This seems like 5 years down the road this is going to turn into a horror story on HN, about "I went to this customer, and they had been running their entire company database on a single Google Sheet, and now are panicking because the secretary accidentally just deleted everyone from pay roll."
As a side note: it's nearly impossible to upgrade to a higher Sheets API rate limit.<p>We tried it all: options in Cloud Console, speaking with support, talking to sales reps. Google simply doesn't want that money and doesn't care if you are hitting limits and want to upgrade.
Is Google Sheets designed for this sort of usage? I would have been worried about hitting some undisclosed limits with the service.<p>A single dedicated server is not that big of an expense either. The site probably could even run on a single high end server as it is now? I guess I wouldn't have considered using something like Sheets given that. Neat idea though.
I guess I'm confused, if you're already running Cloudfront, API Gateway, and lambdas, why you'd bother to make API calls out to Sheets rather than just plunking down a simple DynamoDB? Maybe the data access patterns are more complicated than I'm thinking, or just to capture the built in Forms -> Sheets data entry flow?
I wonder why json over csv? csv should be a natural for sheets.<p>Plus you'd be able to cache them and use diff+patch for quicker updates when reading.
Great writeup, especially the diagrams. v0's manual update handling may seem like anathema to engineers, but is perfect for navigating product/market fit.<p>Though, now that I think about it, things like AirTable do the database thing better than Sheets does WRT being an app backend.