I went to ScaleConf a couple of weeks ago, and have been meaning to write about some thoughts I had, so here it is!

The conference is, as per its name, primarily about scaling, and to be more specific, scaling software, and to be even more specific, a lot of the talks were about scaling software in your start-up.

Most of the speakers were from local companies, that are start-ups, or have recently grown past that stage. There were a couple of international speakers, notably from Facebook and AWS. They have completely different problems to the rest of us.

It was a fascinating look at building scaling systems and I found a couple of common themes kept appearing in most, if not all, of the talks. They seem to be good general practices, not just when you need your software to scale. Below are the seven common themes I identified.

1. Use the cloud

This might seem obvious today, but it’s important to not underestimate the ease and speed that you can scale up using the cloud, not to mention the cost.

One speaker said that any small company can compete with much larger companies in terms of capacity, via the cloud, something that was not possible 5/10 years ago.

2. Make sure you can scale horizontally

You want to be able to drop in another server, or ten and have it just work. You cannot keep buying bigger and bigger machines, as it starts costing large amounts of money, and there is a limit to the size you can buy. One huge server is also a single point of failure…

3. Don’t have a single point of failure

The cloud makes this easy to do by having multiple instances or everything, and it doesn’t cost huge amounts of money. A lot of the speakers mentioned that they still have single points of failure, but in all cases, they were actively working to get rid of them.

4. Use caching

Seems simple enough, but caching can make or break a system and will let you ride out waves of busyness.

5. Use queuing

Use queues to separate your backend processing from the front-end. This allows you to build more loosely coupled systems with the ability to take down parts of the system without affecting the rest. Pretty much everyone speaking mentioned that they were using some form of queuing mechanism. RabbitMQ seems to be the new hotness.

6. Push to production often

There is all sorts of talk about agile in software development, but I realised that being agile in releasing your software is important too. Some of the speakers showed us how they deploy new versions of their software upwards of 20 times a day. Most corporates I’ve worked with, you’re lucky to get a new version into production once every 3 months.

7. Every scenario is different

What works for one scenario doesn’t necessarily work for others, including the things I listed above. You can probably think of a case quite easily where the above do not apply.