Monitive’s current implementation, in matters of architecture, is at version 3. And I believe this architecture to be the best so far, allowing the whole system to scale and spread very easy. Here’s why.
We call all checking ‘jobs’. So when there’s a site to be checked, there is a job that says “we have www.something.com to check every 3 minutes, notify on instant down, etc.”. So the server that controls all the checking is designate ‘Job Manager’. The JobManager connects to various nodes around the world and from there, the actual check is made, the node reports back to the JobManager and the check is done. Of course, this all goes well with a multi-threaded job queue, so that the load on the server is kept under control, and jobs prioritized among them (paid jobs are higher than free etc.).
The key in all this is having very lightweight nodes, that can run on just about any server, becase buying servers all around the world is not required and the whole cost of maintenance drops, making Monitive affordable to everybody.
Another thing that I’ve learned from previous Monitive versions is that the JobManager and the website that the users sees/uses should not be on the same machine. This is because of two main reasons:
- the load on the JobManager is usually higher than idle, so the user that would browse the website or access his account to add/edit monitors would think that performance of the service is poor.
- the website that the users/clients use is accessible to the worldwide web, and prone to attacks of all kinds.
Besides this, we can deploy another JobManager is just a few hours if we find that the one we’re currently using has reached a rather large base of users and it would risk overloading. When having multiple JobManagers, the website’s only concern is where to login or sign-up a new user. After that, the user has it’s checks being done on the allocated server, his data also. The interface is just a website that communicates via API to the assigned JobManager and displays his account’s info and such.
This is why we made it simple, easy to use, easy to scale, easy to run.