"Amongst our weaponry are such diverse elements as: fear, surprise, ruthless efficiency ..... and an almost fanatical devotion to the Pope."
The conventional approach is to make web applications stateless, and store all data in some kind of database. This pattern is so deeply entrenched in our minds that people sometimes forget it is not the only way.
When designing the architecture for a high-traffic web application with millions of users, we decided to go with exactly the opposite approach: no database, but a stateful application, that persists all its data.
Why did we do this? What are the advantages and disadvantages? And how does it work?
The implementation itself -- based on JRuby and a Java ConcurrentHashMap -- is surprisingly simple. But it raises a lot of interesting "secondary" problems, as you cannot simply restart the application. I will explain in detail how we handle persistence, sharding, data migrations and deployment.
Last but not least, I will report how our application is performing in production ..... are we happy with our decision?
Can't wait to see this one! Would you explain whether this is the first time you try something like this in production, or if there have been previous experiences (and what problems did you encounter back then)?
thanks, good point, i'll try to clarify what i mean by "stateful application".
This sounds interesting:-)
By a "stateful application" do you imply something Smalltalk-like where the app and its state is preserved in the same image at all times? Can you please elaborate a bit so that people understand what is this about (and thus are well informed when they vote for your proposal:-)?