System Design (Day - 9)

Database as message queue ( Anti Pattern )

We should avoid this patter⚠️

Let’s say we have Server 1,2 and 3 which is connected to the database, and they are connected to the clients, with the help of the database pooling every 5 or 10 seconds each servers are checking if they get any message from any server or not, like this the server 3 wants to send some message to he server 1, then that server 1 is checking the in the DB for the changes if there is some changes for that server1 then it gets that message, it may do some process and change it state or return to the client, its a standard queue but here database is used as a queue.

Problems

1 . Why we should avoid⚠️ this, There will be frequent polling happens to the database, lot of read request are getting into the db, that the issue, the load of the Database will be increased, that’s not good,
2 . on the other side if your not polling into the db frequently then, that’s also a big issue, because if some server sends any message that has to be delivered to the other server instantly then it not happening here.
this is going to hit the user experience, this approach is inefficient.
3 . The database is only optimised for either reading or writing not for both if both is happening means the load will be more on the Database.
4 . We need lot of space in the database to store all the data communication to the services, or we need to delete that data as operation completed, or we need to mark it completed and update that same data, that’s an expensive operation.
5 . what if we want to add another 2 servers that has to be added in the system that’s very complicated, we have to map that servers into the database and there will be too much load on the DB, we can try by adding another DB for the new servers, but how they can talk to the old servers, so we can use some brokers to talk between the servers or something else, but that’s complicated and not an efficient way of doing these things.

1 . When we have something which is far more better systems that is already there, why we are bothering with this pattern. we can directly use the Message queues.
2 . with that message queues the DB polling is gone the server waiting is gone, communication between them would be so easy. Scalability is also taking care in this message queues, we can add as many as servers we want and as many as message queues we want, so that’s the solution.
3 . When we are using the message queue in our system, it requires some training and some complexity to the system, we don’t have to use the message queues when we are having small applications or there’s not much calls between the servers.

This approach is only bad for the scalable systems, but it’s its ok to design this type of design for the small applications.