Peripia is a multi-user realtime group chat service, focused on "co-browsing": visiting the same sites (or watching the same videos, or listening to the same music) at the same time, and discussing them. It also has elements of an MMO game: the URLs visited by a group correspond to "rooms" in a virtual environment, which the users may explore; rooms have doors leading to other rooms in the same way that the pages at each URL link to other URLs.
Peripia grew out of an established need for a place to work collaboratively on certain kinds of content. The main types of resources the group wished to visit were Etherpad documents and Livestreams. Both of the services mentioned had their own forms of multi-user chat, but neither was exceptionally good (they seemed to be added as afterthoughts) and, more importantly, they were completely disconnected from one-another. I developed Peripia with the goal of providing a framework for chatting, identity, and presence, into which other resources could then be embedded.
I first deployed Peripia on Heroku, but its requirements (for example, the use of websockets) caused me to transition it to running directly on Amazon EC2. Peripia also relies on the Redis key-value datastore for most operations (going through the useful Ohm object layer), but keeps its event history in a PostgreSQL database, as it is infrequently accessed and requires stronger persistence guarantees. Instead of a complex intertwining of SQL and Redis calls, the application layer simply writes all events to Redis; a worker process then prunes batches of event history and moves them to SQL in the background. The application will then read back the history from the first place it finds it.
As I developed Peripia, it separated into two clearly-defined codebases: first, an application server, written in Ruby's Sinatra web framework, which clients initially connect to, which serves the jQuery AJAX client and responds to client requests (e.g. to post new chat lines); and also, a push socket server, using Node.js's Socket.io framework, which clients speak with directly for the rest of their lifecycles once they've established a session with the application server. The application server handles all actual business logic; all the messages the push socket server delivers are received on a message queue (in this case, Redis' PubSub functionality) from the application server.