2 Added CL for update operation.
source | link

I'm new to distributed databases and there are a couple of things I couldn't figure out.
We're developing an application and need to select the right database, this application needs strong consistency on financial data related to users, like deposit and withdraws. I am wondering about tunable consistency in Cassandra, specifically quorum level of consistency.
Imagine the following scenario:
Replication factor is 3.
Initial balance of a user John is 10 on all replicas.
At time t1, an update is happening on John's balance reducing it to 7 (CL=quorum),
Simultaneously, at time t1, a read operation is being run with consistency level set on quorum which is 2 in this case.
Is it possible that the replica on the node where update query is executing on, is not selected for the quorum?
If so, Is it right to assume that the result of read operation would be 10 because there's no write lock?
Overall I'd like to know if it is possible for John to somehow exploit this and spend more than his account's balance.
Thanks.

I'm new to distributed databases and there are a couple of things I couldn't figure out.
We're developing an application and need to select the right database, this application needs strong consistency on financial data related to users, like deposit and withdraws. I am wondering about tunable consistency in Cassandra, specifically quorum level of consistency.
Imagine the following scenario:
Replication factor is 3.
Initial balance of a user John is 10 on all replicas.
At time t1, an update is happening on John's balance reducing it to 7,
Simultaneously, at time t1, a read operation is being run with consistency level set on quorum which is 2 in this case.
Is it possible that the replica on the node where update query is executing on, is not selected for the quorum?
If so, Is it right to assume that the result of read operation would be 10 because there's no write lock?
Overall I'd like to know if it is possible for John to somehow exploit this and spend more than his account's balance.
Thanks.

I'm new to distributed databases and there are a couple of things I couldn't figure out.
We're developing an application and need to select the right database, this application needs strong consistency on financial data related to users, like deposit and withdraws. I am wondering about tunable consistency in Cassandra, specifically quorum level of consistency.
Imagine the following scenario:
Replication factor is 3.
Initial balance of a user John is 10 on all replicas.
At time t1, an update is happening on John's balance reducing it to 7 (CL=quorum),
Simultaneously, at time t1, a read operation is being run with consistency level set on quorum which is 2 in this case.
Is it possible that the replica on the node where update query is executing on, is not selected for the quorum?
If so, Is it right to assume that the result of read operation would be 10 because there's no write lock?
Overall I'd like to know if it is possible for John to somehow exploit this and spend more than his account's balance.
Thanks.

1
source | link

Quorum read consistency in Cassandra

I'm new to distributed databases and there are a couple of things I couldn't figure out.
We're developing an application and need to select the right database, this application needs strong consistency on financial data related to users, like deposit and withdraws. I am wondering about tunable consistency in Cassandra, specifically quorum level of consistency.
Imagine the following scenario:
Replication factor is 3.
Initial balance of a user John is 10 on all replicas.
At time t1, an update is happening on John's balance reducing it to 7,
Simultaneously, at time t1, a read operation is being run with consistency level set on quorum which is 2 in this case.
Is it possible that the replica on the node where update query is executing on, is not selected for the quorum?
If so, Is it right to assume that the result of read operation would be 10 because there's no write lock?
Overall I'd like to know if it is possible for John to somehow exploit this and spend more than his account's balance.
Thanks.