5 ms·
Taking a completely blasé approach to efficiency is potentially as dangerous as becoming hyper-focused on it. Not all businesses become roaring successes, and
by beefsack 10y ago
Taking a completely blasé approach to efficiency is potentially as dangerous as becoming hyper-focused on it.
Not all businesses become roaring successes, and those who achieve moderate success often don't get the resources to fix deep-seated performance or architectural issues (either via engineering and/or throwing hardware at it.) Eventually these technical woes can completely halt momentum and I've seen it even drown some businesses who just aren't able to dig theirselves out of the hole the find themselves in.
People always seem to be arguing for extremes, but the most sensible approach for most tends to be somewhere in the middle.
- eridius 10y agoI agree with your comment. BTW, the phrase you're looking for is "deep seated", not "deep seeded".
- beefsack 10y agoUpdated my post, cheers.
- timewarrior 10y agoAgreed that completely blasé is pretty bad. However in this case being blasé would mean, not working hard to scale when you users are getting a bad experience. A basic stack these days node.js+mongo, go+*sql can easily handle more than 100k users even with one of the worst implementations. Most products don't reach that point!
- beefsack 10y ago> A basic stack these days node.js+mongo, go+*sql can easily handle more than 100k users... That is making some very large assumptions about application workload. For an application which is purely a CRUD interface to a database, yes.
- timewarrior 10y agoAgreed on this point. Many a times there is heavy lifting - recommendations, machines learning etc. However that is don't using specialized technologies in a non user facing process and the results are then dumped into a DB available for a CRUD app. I am hoping that products with such requirements will have some obvious tools for such tasks (Hadoop, Hive etc) and they would find a way to scale such processes with time. So their stack might be go+*sql+Hadoop. Can you please suggest some use-cases which don't fit the above pattern and maybe we can brainstorm. Seems like a fun exercise!
- pbreit 10y agoMost apps are mainly CRUD.
- pbreit 10y agoNo. The most sensible approach is optimizing for developer efficiency while you figure out how to get users and usage. If you are lucky enough to get product/market fit, scaling is easy.
- _pmf_ 10y ago> If you are lucky enough to get product/market fit, scaling is easy. And, as in the case of Twitter, the technology stack is the least of your problems.
- pacaro 10y agoOne approach that I like is to think about scaling in terms of epochs. Each epoch of your system should handle maybe 3 orders of magnitude (let's say users, epoch 1 is 1k - 100k, epoch 2 is 100k - 10m, etc — epoch 0 was your MVP/PoC) When you implement each epoch, do a paper design for the next epoch, this helps you think about how you will get there, and can prevent you from writing yourself into a corner, without over indexing on scaling issues that you don't have yet