I really liked this article. In my mind the general thought was. If you don't think about what you are doing when designing your application, you will run into problems. No matter what you do, you will run into problems. So be prepared to adapt to change or "go bust out the failboat and get-a-rowin'. You're screwed."
Not all of this stuff is obvious to everyone.. For example, I don't really know much about SQL optimisation, when people say things like 'Joins are bad, de-normalisation is good' I kind of just nod my head without really understanding exactly why.
I think this article helps straighten out what might be a few myths about memcached, which is helpful for scalability noobs like myself. :)
I don't know. I thought it was refreshing to read really obvious stuff like this:
So now you're ready. You're building your site fast and abstracting where you can. Brace for change. Be ready to shard, be ready to cache. React and change to what you push out which is actually popular, vs overplanning and wasting valuable time. Keeping it simple is gold here.
You're building something new and you're going to fail at it. Your design will be wrong, you will anticipate the wrong feature to be popular. Dealing with this quickly can set you apart. Being able to slap memcached into a bunch of objects in a few days (or even hours) can mean the difference between riding a load spike or riding the walrus.
