# Handling read conflict in cassandra?

Say we have three nodes(simple replica no sharding) i.e. N1,N2 and N3 with replication factor as 3.

1. As read and write request can go to any node, Say Request write request(to update the same record at same time) comes and goes node N1.

2. Read request comes to read the same document and goes to node N2. I believe it will return stale data as write is not replicated to N2 yet ? Consider the default configuration where i have not tuned the read and write concerns.

3. I believe problem in step2 can be resolved with either of below options

a. In synch replication, Good for strong consistency but bad for performance

b. Tuning read and write consistency as explained at read and write consistency

c. With the help of sharding(if required), where shard key will ensure all read and writes goes to particular node for particular shard key ?

Is my understanding in point 2 and 3 correct?

Mostly yes, but with small correction. You can get the stale data if they aren't replicated yet to another node (replication happens almost at the same time, but still could be delayed because of garbage collection, etc.). You can get strong consistency by tuning consistency levels...

The comment is about point 3c - Cassandra's partitions are replicated to all nodes that were selected as replicas for particular partition - the driver or coordinator node can come to any of them, depending on multiple factors. There is no such thing as an additional sharding key that will route to specific node - all replica nodes are equal.

• You said There is no such thing as an additional sharding key that will route to specific node - all replica nodes are equal. Consider the case of ecommerce application. I believe this is possible in cassandra(like in mongo), For a particular category like Mobile phone,you can send read and write request to particular node(say N1) in cluster instead of sending to all node ? Now further whatever replicas N1 is assigned to, those nodes will also receive those requests. – user3198603 Jun 21 '18 at 1:38
• Yes, by default driver will send request to the correct node that is selected from all available replicas based on the multiple factors - load/responsiveness, etc. This is called "token aware" load balancing: docs.datastax.com/en/developer/java-driver/3.5/manual/… – Alex Ott Jun 21 '18 at 9:20
• By driver you mean coordinated node ? – user3198603 Jun 23 '18 at 8:00
• No. The language drivers are smart enough to avoid going to coordination node and reaching directly one of the replica nodes, so at least for one node, read or write is performed locally. – Alex Ott Jun 23 '18 at 8:06
• Ok looks like it meant driver installed at client side which knows upfront which node it will find record based on token value/load/responsiveness ? – user3198603 Jun 23 '18 at 8:09

You cannot accomplish 3a (in sync replication) because Cassandra doesn't do that. You can use the write consistency ALL (as you mention in 3b) which will eagerly attempt to write to all replicas. Even if the write says it fails it still may have worked (just the nodes didn't respond in time).

About point 2, you mentioned you haven't tuned read and write consistencies, but depending on the driver you use there may be different default consistencies so it's impossible to say if it's correct. I made a table below describing the scenarios. This table assumes the write query responded with a success.

Write CL | Read CL | Result of query in point 2
---------+---------+---------------------------
ONE      | ONE     | Possibly stale
ONE      | QUORUM  | Possibly stale
ONE      | ALL     | Fresh
---------+---------+---------------------------
QUORUM   | ONE     | Possible stale
QUORUM   | QUORUM  | Fresh
QUORUM   | ALL     | Fresh
---------+---------+---------------------------
ALL      | ONE     | Fresh
ALL      | QUORUM  | Fresh
ALL      | ALL     | Fresh