First of all, I'm glad you have chosen Fan-out-on-write over Fan-out-on-Read because, reading how your newsfeed works it appears to be operating similar to Twit

First of all, I'm glad you have chosen Fan-out-on-write over Fan-out-on-Read because, reading how your newsfeed works it appears to be operating similar to Twitters & I believe I have a nice solution for you :) I'd use BigTable as the data is distributed among a cluster by rowkey & then individual records are stored as columns which are then sorted by column name. As BigTable stores are designed to deal with relatively unbounded numbers of columns and considering that each timeline is given a unique rowkey e.g. username & a column is inserted to represent each event - the column name also has a time sortable unique ID (this becomes important in a second) & the column value would contain the event's data. As a result, this type of schema would see a timeline which potentially could contain hundreds of events (even though you're currently capping it at 300) and can be read from a single node with a few disk I/Os & the time-sorted ordering (as I mentioned above becomes important here) allows it to be efficiently paginated by using a range slice operation. The result is an append only commit log meaning that insertions are pretty cheap (because afterall this is what is important!) and you usually can do tens of thousands per second per node! I believe that BigTable would be best suited for this which means that you're really looking at using Cassandra as it can stay fully available for writes and it reads during a network partition. I did consider MongoDB to be used but it only has a limited document size limit so I ruled it out. Anyway back to Cassandra... as things are going on in your timeline for the users, additions/subtractions are commutative so you can easily exploit the likes of Amazon DynamoDB [1] so you can fully exploit the weakest consistency guarantees of Cassandra. Its important to note the system would require queues & workers to perform the fan-out operation, event deletions & updates to the list of feeds for each users timeline but you could make this part of the background system. Similarly, as the workers won't immediately get around to permanently mutating the timelines of your users I would recommend that you also cache the mutations in memcached so you can temporarily perform the data scrubbing at read time before the workers perform the task which will considerably improve consistency. [1] http://aws.amazon.com/dynamodb/ http://aws.amazon.com/dynamodb/