I've always wanted to use such a technology to build a write-behind persistence mechanism. Let's say that you want your data in a relational DB (for reporting, company policy, integration, whatever) but can stand a very small risk of losing a few seconds worth in the case of a huge failure. You'd gain by avoiding the latency of network-to-db and disk forcing.<p>So, you write DAOs that "persist" to a queue and to a shared map(s). When you read, you look in the map first and go to the DB upon failure. Queue consumers persist messages (inserts/updates) to the db. After your application reaches a steady state, you shouldn't have to read from the DB much at all. And, you could build an eager loading mechanism for efficient start-up.<p>Even without async persistence, I'd prefer one of these solutions over memcached/MySQL replication hackery.