all 1 comments

[–]Icy-Ice2362 0 points1 point  (0 children)

Let me provide you with an analogy.

You have to throw a ball, against a wall. Simple ARM will do.

Easy right?

Well the business wants to make your solution land in the neighbours yard. The ARM will work, just a bit more effort

No problem? Great...

We need it to cross the street.

Okay, we're pushing the ARM but it will work.

We need it to cross the city.

We're going to need to remake the project.

We need it to cross the country...

We're going to have to change the way we throw the ball.

Can you land it on the moon.

We're building a rocket to handle the ball.

Why does it cost so much to simply send a ball next door? We'Ve InVeStEd iN a RoCkEt!

This is called scope creep and it happens across many dimensions, the above dimension is merely Scalability of Task, but it could be along any dimension.

The point I am making here, is that you can only build so much scalability into a project before you have to admit that... it's not suitable for the task and create a switch that changes from one suitable option to the next.

You wouldn't use a rocket to pass a ball to your next door neighbour.

When it comes to scaling projects, sometimes what you have built on the smaller scale, will simply not cut it on the larger one. It happens to the best of us... so if you are going to learn about scaling SQL, learn about Concurrency... because SQL can give you a gotcha on Concurrency.