Database as IPC

At the time of writing, I'm currently over the Atlantic, on my way from London to San Francisco, which is probably a good thing as it means my neck is decisively out of the reach of some previous developers I've worked with.

Let me clear this up for you; your database isn't a message queuing system. You don't use it schedule jobs or queue up tasks to be completed. If you need something to do that, use a queuing system. Your database is for data...the clue is in the name; don't shove temporary messages in there.

There are many reasons why this is a bad idea. One major issue is the fact that in databases there is no real way to not enforce a policy by which you can guarantee that a double-read will not occur, and that is by utilizing row locks. This in turn, results in processes (either incoming out outgoing) being blocked, which in turn results in processing only being able to be done in a serial fashion.

Furthermore, in order to check if there is any work to do you end up essentially counting the rows of data in the database to see if there is work to do; you run this on a continuous basis. MySQL doesn't support push notifications; unlike PostgreSQL it doesn't have the NOTIFY command to pair with a LISTEN channel.

Also note that when you merge a job queue with a database table that stores real data, you also invalidate the cache every time you complete a job and update a flag, in turn making MySQL far slower.

In short, it results in your database performing worse and can force it to slow critical messages to a standstill. You must be careful not to turn your database into a job queue by having this functionality sneak up on you; instead, use the database exclusively for data, and bear this in mind when extending your database.

RabbitMQ provides an open source queuing system with some great PHP SDKs.