# Consistency level Issues

**URL:** <https://forum.scylladb.com/t/consistency-level-issues/2581>\
**Category:** ScyllaDB\
**Tags:** data-model, repair, consistency\
**Created:** [August 24, 2024, 9:17pm UTC](https://forum.scylladb.com/t/consistency-level-issues/2581 "2024-08-24T21:17:46Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![rohit\_ranjan](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.scylladb.com/rohit_ranjan/32/1092_2.png) [@rohit\_ranjan](https://forum.scylladb.com/u/rohit_ranjan)\
**Post date:** [August 24, 2024, 9:17pm UTC](https://forum.scylladb.com/t/consistency-level-issues/2581/1 "2024-08-24T21:17:46Z")

</div>

Hi,  
My cluster is a multi-dc setup with 4 nodes and a replication factor (RF) of 2. I’m using the default consistency level (ONE) for both read and write operations. However, for a very small portion of reads (less than 0.1%), I’m experiencing inconsistencies where the same request sometimes returns a null value and other times a non-null value.

Although I am using consistency level ONE, I expect scylla to be eventually consistent. But I am experiencing this inconsistent behaviour in reads even after 5-6 hours of writing the data. Is there a max time after which read consistency can be guaranteed? And what is the recommended consistency level for production systems? My use-case requires the data to be eventually consistent after 1-2 hours of writes.

---

<div class="post-metadata">

**Author:** ![tzach](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.scylladb.com/tzach/32/172_2.png) [@tzach](https://forum.scylladb.com/u/tzach)\
**Post date:** [August 26, 2024, 1:32pm UTC](https://forum.scylladb.com/t/consistency-level-issues/2581/2 "2024-08-26T13:32:02Z")

</div>

Are you using RF of 2 per DC?

With CL=1, if a write request (mutation) got lost somewhere between the coordinator and a replica, the coordinator will still return a success ack based on the one replica that did succeed.  
This means a replica still needs to be updated; there is no way to know that. In this case, a Read with CL=1 might get a stalled value.

Only a repair operation will bring all the replicas back into sync.  
You can mitigate this issue using RF=3 and CL=QOURUM for reads and writes.

More here

> **[ScyllaDB Architecture - Fault Tolerance | ScyllaDB Docs](https://opensource.docs.scylladb.com/stable/architecture/architecture-fault-tolerance.html)**
>
> ScyllaDB is an Apache Cassandra-compatible NoSQL data store that can handle 1 million transactions per second on a single server.

> **[ScyllaDB Repair | ScyllaDB Docs](https://opensource.docs.scylladb.com/stable/operating-scylla/procedures/maintenance/repair.html)**
>
> ScyllaDB is an Apache Cassandra-compatible NoSQL data store that can handle 1 million transactions per second on a single server.