Today in the world of micro-blogging, problems of twitter have become nearly household news. This has made site developers think about how can they make their site stable and scale with good Quality of service to the user (you , me , everyone). This post is about how we have planned kwippy, the whys and how we ensure that kwippy, the whale does not beach. Here are some pointers to the open source tools we use:

1. Python - the core language we use to script everything that runs
2. Django - “Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design” -
   • This is equivalent to Rails for twitter, the choice was kind of obvious as we needed to develop stuff rapidly without losing out on speed or scaling issues with respect to the platform.
   • we initially considered cakePHP and Code Igniter, they were blazingly fast … but code maintenance was a pain. That is very crucial, if we are to keep implementing new features real fast.
   • RoR was never in.No offense to the RoR community/developers but we’ve had experience with it previously, and it is too slow for a production site in my view. Too many problems associated with mongrels, file uploads and so on ….Things might have changed for better with RoR since then
3. MySQL - a really fast database that can scale, all of us have experience with it hence the default choice.
4. Linux - Our servers are debian, its clean and our teams understanding about it is pretty good.
5. Nginx - A pretty fast web server from russia(with love). Its pretty fast and must admit has done the job optimally.
6. Memcached - high-performance, distributed memory object caching system.
7. Lots of other tools for IM , mailing.

To be a fast and stable site, so very basic things were done which are not a part of the django framework. Lets list some of the most obvious ones:

1. All the static files (javascript, CSS, images) are cached infinite time. Which means that once downloaded onto the user’s browser they are not downloaded again and again, unless of course they are changed. This reduces the render time and the web server load.
2. Take time-consuming things offline. We do removal/hiding of repeated kwips offline, it is pretty slow if a lot of messages were to be checked for repetition together.
3. Split the services so that down-time on one does not affect the other. The attempt is to split the IM services from django from Mail services from search services, this will enable scaling of individual components separately and in addition ensure that one service mal-functioning does not take down the whole site.

A lot of these concepts can be seen when you load kwippy on your browser. Lets say we have many many more users in the next couple of months, can we scale to that challenge? I can say a confident yes and here are some ways we plan to scale.

1. Cache the most accessed parts of the site. This is in the pipeline, and based upon how flickr scales, conceptually it is nothing but a lot of caching using a reverse proxy server like squid.
2. Optimizations of code all over the site. We have kept the proverbial 20% of optimizations when we need it, i would like to say our Quality of Service is pretty decent right now. I would want to use this as the trump card.

This might sounds like you have heard it before or read it before. But the truth is that they are not practiced often.

Everything said and done, we are taking firm and small steps, preparing for the marathon , any suggestions and discussion are most welcome. Catch me at http://kwippy.com/dipankar or email me at dipankar[at]kwippy.com.

Below is a basic architectural diagram of how we have placed all the blocks together to give you the current services. Forgive my sense of color, its truly warped (no wonder, I am the back end guy;) ). If you are looking for something more professional, sorry mate I had fun making the color boxes ……