Scaling Simple Messaging System

Now, we have the simple messaging system ready, we have to think about its performance. Also known as scaling. What is scaling and how do we scale our simple messaging system ?

The definition of scaling is to get it ready when the data becomes big and traffic increased. Normally we will start from small members with small traffic. As our system grow with use, we will need to make sure that the system is able to handle the ever increasing traffic and usage.

A good example is by putting numbers. Will our simple messaging system be able to handle 1M transaction / second with 10M data inside the database ? Compared to our initial 100k transaction / second with 1M data inside the database ?

So, we can say can a 10x increase in traffic and data be handled by our existing system ?

First, we must make sure that the system is designed to be able to cope with future changes with little or no modification in the future.

If we look at the table relationship. The table message is directly linked to table user, maybe user_groups. This is still OK. For me, the maximum SQL JOIN for tables are 3. There can only be a maximum of 3 tables inside one SQL query. The optimum is of course a single query in one table.

One possible change is to add the user name directly to our message table. So, we store the user_id and user_name inside. This will help a lot by reducing the query to 2 table, if we only store the user_id inside the message table.

The potential problem is if the user changes his name, which of course must never happen in reality. But, it can happen. Maybe the admin mistype his/her name, so he/she correct it by him/her-self.

Should that happen, we can simply update the table message to reflect the changes. Or leave it as it is.


Next, we will need to check that the table can handle a lot of message, especially message_id. This concerns the integer type for message_id. It is not fun if we have only 65536 maximum message_id and we then have like 100k messages to be stored. So, you should check with your database manual for this information.

From the MySQL manual, the default integer value is good because it can store up to 4.294.967.295 in unsigned form. So it can store 4 million+ data, which should be good enough for a start.

Believe me, it is not going to be very fun when you run out of message_id, because you will have to stop the entire system. And figure out how to handle the situation. Which can take days to solve.

I am sure there are more things we can do to make sure the simple messaging system scales well. For now, those are things that I can think of.

Can you think of other possibilities that we must take care of ? Please share in the comments section below.