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 actually goes to great lengths 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.
Note
Accordingly, there's a performance penalty in using lightweight transactions. As a result, 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 that 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 a Rich Site Summary (RSS...