Lightweight transactions allow us to maintain data integrity in the face of concurrent updates but they don't do it for free. Because of Cassandra's distributed architecture, it's actually quite involved to guarantee that the data is in a certain state before modifying it, as all the machines that store that piece of data need to be in agreement. Accordingly, there's a performance penalty in using lightweight transactions; thus, you shouldn't use them in situations where you don't need to.
As we discussed earlier, concurrent insertions aren't a concern for any table that uses UUIDs that are generated by the application or by Cassandra at row creation time. Simply using UUIDs guarantees we'll never have a row key collision.
Another scenario in which we can skip conditional inserts is when we have a globally unique natural key. For instance, if you're building an RSS (short for Rich Site Summary) reader, you might...