undefined | Better HN

0 pointshobofan10y ago0 comments

I disagree with that statement.

Of course a design that works at 1x doesn't always work a 10000x, but why shouldn't a design that works a 10000x not also work at 1x?

At least for technical scalability the answer almost always lies in overhead. Yes, while the system scales perfectly linearly at O(n), the hidden constant is often neglected, which means at small values of n the solution becomes unfeasible. So while Cassandra might for one of my use cases be the perfect candidate due to its feature set and linear scalability it becomes unfeasible at a small scale because I have to run at least 3 nodes with high overhead (because Java, sigh) + an additional 3 nodes with Zookeeper with high overhead (because Exhibitor + Curator, all in Java).

/rant, I don't like bashing on Java but overhead is definitely one of its weak spots, and here is where it comes into play.

0 comments

5 comments · 3 top-level

gaius10y ago· 2 in thread

Scaling down is always easier than scaling up, because you are going back over known territory. Scaling up is hard because it takes you into unknowns. Rumsfeld's Theory applies.

hobofanOP10y ago

Yes, it is easier but is also very rarely done, since if you have scaled another 10x you don't care about the previous stage of scaling and have little incentive to keep the constant factor at that stage low.

I can understand why such systems are built the way they are, but I still find it sad, since it breaks the expectations of open source software, and creates a chasm between startups at the beginning and end of a big scaling phase. It more or less forces you as an early stage startup to use an inferior design which you know won't scale up beyond a certain point, even though know about a superior design that theoretically scales down to your current requirements.

gaius10y ago

If you design a system to support 10x your current workload, you are likely to get a well engineered solution that delivers the performance you need at a price you can afford. If and when you reach 10x, you will have a good body of knowledge to help you do the next 10x. That takes you to 100x. Systems that grow that much are exceedingly rare. The odds of your startup being the next Facebook are incredibly low. But this strategy will get you there, one step at a time.

If you sit down and try to design a system to support 100000x your current workload, you are likely to end up with an over-engineered and very expensive mess, then by the time you reach 10x you realize you should have done it differently because in practice the bottlenecks aren't where you thought they'd be. This strategy will bankrupt you before you get to even 10x.

This is how you tell who has really scaled systems, from those who only wish they had that problem.

tango1210y ago

I understand your point. Out of curiosity, can you take examples of software that work at 10000x and also at 1x equally well?

ssmoot10y ago

That's not really a scaling problem though. It's an availability one. Cassandra just doesn't compromise on it.

You have alternatives, and it doesn't really have to mean a whole lot of extra work until you get to "crazy" levels. No one wants a StrategyFactoryFactoryVisitorImpl, but on the other end of the spectrum you can get a ton of mileage out of a few Facades in the right place.

Scalability is an optimization topic. But just like the premature saying everyone knows, the follow up that is less acknowledged is maybe the more important part (IMO).

j / k navigate · click thread line to collapse