It appears you are aware of the tombstones affect that leads people to label this an anti-pattern. Without "due" or any time based value being part of the partition key means you will still get a lot of buildup. You only have 1 partition per shard which just linearly decreases the tombstones. That isn't likely to be enough to really help in a situation of high queue throughput, especially with the default of 4 shards.
You may want to consider switching to LCS from the default STCS since re-writing to same partitions a lot. It will still use STCS in L0 so in high write/delete scenarios, with low enough gc_grace, when it never gets higher then L1 it will be sameish write throughput. In scenarios where you get more LCS will shine I suspect by reducing number of obsolete tombstones. Would be hard to identify difference in small tests I think. Whats the plan to prevent two consumers from reading same message off of a queue? You mention in docs you will address it at a later point in time but its kinda a biggy. Big lock & batch reads like astyanax recipe? --- Chris Lohfink On Oct 5, 2014, at 6:03 PM, Jan Algermissen <jan.algermis...@nordsc.com> wrote: > Hi, > > I have put together some thoughts on realizing simple queues with Cassandra. > > https://github.com/algermissen/cassandra-ruby-queue > > The design is inspired by (the much more sophisticated) Netfilx approach[1] > but very reduced. > > Given that I am still a C* newbie, I’d be very glad to hear some thoughts on > the design path I took. > > Jan > > [1] https://github.com/Netflix/astyanax/wiki/Message-Queue
