Single data group, global read scaling
======================================

The global read scaling pattern adds multiple subscriber-only groups to
a central write group of three or more nodes. Connection Manager handles
write leader routing within the write group automatically, while each
subscriber-only group can have its own load balancer and scaling policy.

Subscriber-only nodes receive all changes but can’t write or participate
in consensus. Groups can be added and removed dynamically without
affecting the write group, and the write group itself can be distributed
across multiple regions or availability zones for higher availability.

.. figure:: /images/single-data-group-global-read.png
   :width: 70% 
   :alt: Single data group global read scaling topology

   Single data group global read scaling topology

Diagram legend
--------------

Symbols represent node types, group containers, and connection types.

.. figure:: /images/legend.png
   :width: 70% 
   :alt: Diagram legend showing node types, group containers, and connection types

   Diagram legend showing node types, group containers, and connection
   types

When to use this pattern
------------------------

This pattern suits read-heavy workloads requiring workload isolation,
with separate groups for analytics and reporting, API read traffic,
configuration distribution, and regional read replicas. Each group
scales independently based on its workload.

The advantages of this pattern include the following:

- Scales reads massively by adding nodes without affecting the write
  cluster.

- Offloads reporting and analytics from the production write path.

- Subscriber-only nodes can be placed in additional regions for local
  read latency.

- Supports dynamic scaling by adding and removing read nodes without
  cluster reconfiguration.

- Isolates heavy read workloads from transaction processing.

There are some limitations to keep in mind:

- Subscriber-only nodes have replication lag and aren’t suitable for
  read-after-write consistency requirements.

- Applications must route connections explicitly, distinguishing between
  subscriber-only nodes and data nodes.

- Subscriber node lag or downtime increases WAL retention on data nodes,
  which affects disk usage.

Recommended commit scopes for this pattern
------------------------------------------

- **Majority protect**: synchronous replication to the majority of the
  data nodes in the write group. The most commonly recommended scope for
  production use.

- **Adaptive protect**: synchronous replication to the majority of nodes
  in the write group when available, degrading automatically to
  asynchronous replication after a configurable timeout. Recommended
  when using two data nodes and one witness.

- **Local protect**: asynchronous replication with durability only for
  the local node. Not recommended for production use.

Commit scopes make different trade-offs across performance, durability,
consistency, and scalability.

.. figure:: /images/single-data-group-global-behavior.png
   :width: 70% 
   :alt: Single data group global read scaling behavior diagram

   Single data group global read scaling behavior diagram