Stateless services have some huge advantages, analogous to pure functional programming, especially when you truly commit to purity. The surface area for verfica

Stateless services have some huge advantages, analogous to pure functional programming, especially when you truly commit to purity. The surface area for verfication and optimization is far more manageable, without having to worry about an internal state space. There's a dead-simple horizontal scalability story and reliability isn't much of a concern due to the fungibility of individual instances. Any real service must, of course, have state somewhere. I've had a lot of success being very intentional about factoring state into the smallest possible interfaces, ideally contained in well understood products like databases. Much like pure functional programming, it's not necessarily easy to go truly stateless. I've plenty of "RESTful" architectures get bogged down in the complications seemingly harmless stateful optimizations like caching layers, often to cover up poor performance of runtimes like Ruby and Python. It's very tempting to take a couple shortcuts and end up with the worst of both worlds. Of course, stateless isn't always the best way to go, especially once you start getting to the exotic territory inhabited by the examples in the article. I think for 99% of us, those are problems we'll never experience. I'd be interested in seeing a case where statefulness really let someone down, who wasn't at Facebook/Twitter/Google scale.