How we built our realtime app, Filmgrain, part 1 - the backend

Re:How we built our realtime app, Filmgrain, part 1 - the ba... by samyxp17 on Tuesday June 25, 2013 @05:08PM (#5942468)

A Redis only system is very interesting but are you doing any kind of replication or clustering and would you recommend it as a main datastore for mission critical user data (accounts, profile, purchased...) ?

[ Parent | on HN ]

Re:How we built our realtime app, Filmgrain, part 1 - the ba... by nasalgoat on Wednesday June 26, 2013 @11:15AM (#5946569)

You can do it with shared storage and/or replication without worrying about data loss on a failure.

The key to scaling and maintaining HA with redis is using clustering, either built into the app or through something like nutcracker (https://github.com/twitter/twemproxy) and making sure you properly balance.

The performance of redis makes it very worthwhile to deal with the persistence/HA issues.

[ Parent | on HN ]

Re:How we built our realtime app, Filmgrain, part 1 - the ba... by Guzba on Tuesday June 25, 2013 @05:21PM (#5942542)

Right now we don't have user accounts or anything mission critical to store. (Everything we use Redis for right now is essentially app state and we use it to managing cross-machine communications.)

When we have user accounts and other things like that, we'll have to think about how to do that the most reliable way as well, which may be Redis or may mean bringing Postgres into the mix. I think there's a lot of benefits to keeping the variety of technologies down so if we were to bring in another, it would need to offer something compelling that our current mix doesn't offer.

The major theme we were trying to highlight in this post is just how far Redis can take you if you're trying to build a component-based backend and need a way to handle the communication as well as the state of the system.

[ Parent | on HN ]