3 ms·
> 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 t
by danielmarkbruce 2y ago
> 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.
- sneak 2y agoYeah, 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 2y agoThis 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 2y agoBut it's such a great idea. You too can soon have 700 microservices.
- bigbacaloa 2y ago[dead]
- schnable 2y agoI 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.