How does a PN-Counter support both increment and decrement using only grow-only counters internally, and why doesn't it work to just merge a single counter value using max even if deltas can be negative?

## How a PN-Counter is built A **PN-Counter** (Positive-Negative Counter) is built by composing two independent G-Counters internally: `P`, which accumulates all increments, and `N`, which accumulates all decrements. Each is a standard grow-only counter — a vector with one slot per replica, where a replica only bumps its own slot, and merging two vectors takes the element-wise maximum per slot. - To increment the PN-Counter, a replica bumps its own slot in `P`; to decrement, it bumps its own slot in `N` (both operations only ever increase the relevant internal number). - The externally visible value of the counter is computed on read as **sum(all slots in `P`) minus sum(all slots in `N`)**. - Merging two PN-Counter replicas is simply merging `P` with `P` (max per slot) and `N` with `N` (max per slot) independently — no new merge logic is needed beyond what G-Counter already provides. ## Why a single scalar fails This design exists because a CRDT's merge function must be well-defined purely from the states being merged, with no access to shared history or arrival order. A single scalar that both increments and decrements apply directly to cannot be merged this way: if replica A's counter shows 7 and replica B's shows 5, there is no way to tell, from the numbers alone, whether - B did a decrement A hasn't seen yet (in which case merge should reflect the decrement), or - B simply hasn't caught up to some of A's increments yet (in which case merge should keep moving toward 7). Splitting into "all my increments, ever" and "all my decrements, ever" resolves the ambiguity: both P and N are monotonically growing, so each independently supports the same unambiguous max-merge rule a G-Counter uses, and subtracting the two sums at read time reconstructs the true net value without ever needing a decreasing merge. ## What it costs The cost of this design is roughly **double the memory** of a G-Counter (two vectors instead of one) and **read-time computation** (two sums and a subtraction), which is negligible for small replica counts but adds up if the counter is read at very high frequency across many replicas with large vectors. A more interesting trade-off is what's not preserved: PN-Counter tells you the net current value, but it does not preserve the intermediate history of increments/decrements beyond the granularity your own snapshotting provides — it collapses history into two running totals, same as any counter. ## The mistakes 1. The classic mistake is trying to shortcut the design by keeping a single scalar per replica and merging with max even though decrements are allowed — as reasoned above, this silently breaks: a decrement looks exactly like "stale, hasn't caught up," so the merge will happily discard it and the counter can never actually go down once merged with a replica that saw a higher pre-decrement value. 2. Another subtler mistake is letting the exposed "value" be cached rather than recomputed as `sum(P)-sum(N)` on every merge — if the cached value isn't recomputed after every merge, the exposed value can lag behind the true post-merge state once concurrent increments and decrements from multiple replicas are involved. ## Where it ships PN-Counters are the standard "net delta" counter type in systems offering native CRDT support: - **Riak KV** ships a PN-Counter type directly usable from application code for cases like tracking a "net votes" or "inventory adjustment" figure across geographically distributed replicas that need to accept writes locally without a coordinator. - **Akka's Distributed Data** module provides a `PNCounter` CRDT for cluster-wide gauges (e.g. "number of active sessions" across nodes) where losing real-time exactness for always-available local writes is an acceptable trade.