Tim Lossen
Ranked 24 in Phase 2 with a weighted final score of 156

About the author

"Amongst our weaponry are such diverse elements as: fear, surprise, ruthless efficiency ..... and an almost fanatical devotion to the Pope."

I <3 State

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?

Previous Next


  • 69921eedd141eac43c7f9cddc5891ca1?d=retro Josep M. Bach suggested 8 months ago

    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)?

  • The proposal author responded 8 months ago

    thanks, good point, i'll try to clarify what i mean by "stateful application".

  • 1bb0c9acde5c36e515da3d0da95ea748?d=retro John Pagonis suggested 8 months ago

    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:-)?