I am currently working on a browser game. It's not my first one, but it is the most complex I have worked on to date.
In the past, I would code everything in PHP, and have functions checking whether certain maintenance operations were required or not, carrying them out when necessary (for instance, if players must receive 50 gold every day, I would have a function which checks when was the last time 50 gold were added to each player; if it's less than 24 hours, do nothing; if it's more than 24 hours, then add 50 gold * the number of times 24 hours have elapsed (in case no one has accessed the website in more than a day)).
This worked, but was rather inelegant and resulted in a quite large and complex codebase as the game's features grew.
For my current architecture, I am thinking of having a very elementary front end that just fetches the data from a database and renders it in the browser; when players perform actions from this front end, it adds the actions to an event queue.
Then I would have completely separate server code running 24/7 (written in C++ or Python or whatever) which would be continuously polling the event queue, updating the database accordingly, and also run a set of functions at various intervals (for example, add 50 gold everyday), a bit like cron would.
I think this architecture will be better, as it will allow me to better separate game logic and front end; it will scale better; and it will just make for better code overall.
Are there any considerations/drawbacks with such an architecture?