I downvoted for the following reasons:
I find these “you are doing X wrong” titles offensive.
Considering the author wants to tell me how to scale, they are using an RDBMS for their social graph?
The author is using strings to create SQL queries. Not even funny.
I disliked how the author threw out concepts without really describing pitfalls that someone trying to scale would probably need. He just mentions that cache is a magic thing and then does little to describe how to best use it. Even when he talks about sharding he just ends it by saying “it’s complex, deal with it later.”
I’ve added a little more info. However, the message on sharding is still: don’t deal with it unless you really have to (plus, there is a link to another post that will explain in detail how, should you need to)
Doesn’t matter what the example is/was
Yes it does. This post is making a statement about how to solve problems in a scalable way and as its example is using the, known, least scalable way of solving a social graph. This author should be laughed out of the room.
This author should be laughed out of the room
Pretty sure you noticed that was me. Can’t say I appreciate the snark.
As mentioned, I agree the choice of a social graph was not the best fit given this context.
However, Facebook’s social graph (using TAO) still persists the data to MySQL and relies on it to replicate to slaves. Way back before they built TAO, they also mostly relied on memcached - like in the example.
Anyway, I’m done discussing this. I’ve removed the example since I agree it was pretty poor & didn’t contribute much anyway.
[Comment removed by author]
It’s definitely really easy to go down that rabbit hole of “designing for scale” when you don’t have a functional product yet. However, I think a key part of this is that you have to be ready to refactor your code when it’s the right time to do so, if that makes sense. You can’t be afraid to identify what appears to be holding you back and fix it as it arises.