Peloton is a fitness company. Peloton sells a high-end indoor stationary bike attached with a 22″ Android tablet to which we stream live cycling classes from our flagship studio in New York City. I am a DevOps Engineer and my role is to scale and maintain our cloud infrastructure.
At Peloton we needed to store and retrieve packet data from active Peloton stationary bikes in real time.
My team members had knowledge of Cassandra from working on past projects and had a positive experience with the technology. We were aware of other technologies that compete with Cassandra but chose Cassandra because we needed to build our application in a short time and it made sense to go with a familiar technology.
We started with version 2.0.3 and recently upgraded successfully to 2.0.10. We deploy with Chef; we can easily add a node to our existing cluster using knife bootstrap. We are currently in one region of AWS.
Cassandra allows us to scale our real time data storage horizontally by throwing hardware at the problem. We find that an appropriately configured Cassandra cluster is a scalable database backend. The ability to upgrade server software without causing any downtime in our application is a true luxury.
There can never be enough monitoring and logging for Cassandra.
The replication factor should be high enough for your read/write consistency level. For example, if you are reading and writing at a quorum, the replication factor should be at least three if you want high availability. Ask yourself whether you really need quorum and whether you can get away with a consistency of one.