[danielmarkbruce]

> Sure, you could “just” murder your database with table-scanning queries that join every single table and hope that you’ve provisioned a beefy enough machine to handle the load “for now”. Just like your plumber could “just” fix a pipe leaking on the floor by shoving a bucket under it and telling you to empty it every week.

This is the actual solution in the vast majority of circumstances. If after x days you realize you've made a terrible mistake, that's a nice problem to have.

[schnable]

I had the same feeling when I read this. This engineer needs a product person pushing them to rethink their architectures, and shows that it's helpful to have technically minded Product Managers that can call BS on engineering when warranted.

[sneak]

Yeah, the whole article seemed “webscale for webscale’s sake”, despite describing a product just a few steps beyond MVP.

Overengineering abounds. It’s easy to feature flag something and roll it out only to a fraction of the userbase and see if the database falls over, or if you’re biased toward acronym/resume-driven-development.

We’re almost certainly talking about megabytes here, not terabytes.

[et1337]

This line at the end of the article triggered me:

> You can invest [your spare time] each week towards something bigger like a pub/sub system so that you can pull a new microservice out of your monolith.

[danielmarkbruce]

But it's such a great idea. You too can soon have 700 microservices.