A common concern about strict serializability is that it limits throughput. On the write path, this is partly true: the two-phase commit protocol and synchronous replication add latency that a weaker consistency model would not incur. On the read path, however, strict serializability does not require reads to go through the leader, and Grit Core Lab takes advantage of this to scale read throughput horizontally.
How Read Replicas Work in Grit Core Lab ¶
Read replicas receive log entries from the leader via the same replication protocol used for durability. In Grit Core Lab 3.2, replica propagation latency is 12 ms under normal network conditions. The client library includes a routing layer that directs read queries to the nearest replica based on network latency. Write queries always go to the leader. The application does not need to manage this routing manually.
Consistency Guarantees on the Read Path ¶
Reads from a replica are consistent as of the most recently replicated log entry. A read that arrives at a replica before the relevant log entry has propagated will be served from the replica's current state, which may be up to 12 ms behind the leader. For applications that require read-your-writes consistency, the client library supports a session option that routes reads to the leader for a configurable period after a write from the same session.
Scaling Read Capacity ¶
Each additional read replica adds proportional read throughput. A four-node cluster with one leader and three replicas can serve three times the read throughput of a single-node deployment, with each replica handling reads independently. Replicas can be added without downtime and without reconfiguring the write path. In the managed cloud deployment, replica provisioning is handled automatically based on a target read latency threshold that the customer configures.
When to Route Reads to the Leader ¶
For workloads where reading a value immediately after writing it is a correctness requirement (for example, a balance check immediately after a deposit), reads should be routed to the leader. The client library's session-level read-your-writes option handles this automatically for the duration of a session. For reporting and analytics workloads where a 12 ms staleness is acceptable, replica routing reduces load on the leader and improves overall throughput.
The full capability list describes the read replica routing configuration in detail, including the session-level consistency options available in the client library.