We use Cassandra extensively in one of our software products. Its "active-active" clustering, and being able to perform a write on any node, is the primary reason why we use it. However, just as you mentioned in your post, Steve, we also still have, and rely upon, a regular RDBMS for other data within the product.
Some interesting aspect of Cassandra include how you distribute your cluster nodes, are they all contained within one "data center", or do you have multiple "data centers" defined? What replication factor do you choose? What consistency level do you choose?
There is a concept/feature in Cassandra called "lightweight transactions", but we don't use them. Instead, the general recommendation is that the application code provides the SQL statement you want to perform, and then another statement to effectively undo the first statement, if it fails. So for example, if I want to update a user's email address from 'email@example.com' to 'kevinSql@server.com', I would essentially make two UPDATE statements. The first would be your normal UPDATE statement to update to the new value. But if that fails, we need another statement to try and set the value back. So that means we need the original value. How do you know or get the original value? Well, you have to make a call to read the database first, at some point, before trying to update it. So that's a bit odd and doesn't seem very performant. Obviously, your use cases will vary.
And then, one last thing that I'm a bit biased on, is that Cassandra is written in and runs on Java. And they are no longer making new releases that run on Microsoft Windows OS.