All topics
36 / 66
Apache Cassandra

Counters

Understand Cassandra's specialized counter column type for distributed increment/decrement operations.

A view count needs incrementing by many clients at once. Doing it the normal way does not work:

A counter column is like several people simultaneously adding tally marks to a shared scoreboard from different locations, with someone reliably summing all the tally marks whenever anyone checks the current score — but if a marker isn't sure their mark was recorded and adds it again just in case, the score can drift slightly high.

Key Concepts

1
    SELECT views FROM posts WHERE id = 7;      -- 100
    UPDATE posts SET views = 101 WHERE id = 7;
2
Two clients both read 100 and both write 101. Two views, one recorded. There is no views = views + 1 for a normal column, because that would require reading before writing.
views = views + 1
3
A counter column is the exception. You send the change, not the value:
4
    UPDATE post_counts SET views = views + 1 WHERE post_id = 7;
5
Replicas apply the delta, so concurrent increments add up instead of overwriting each other.
6
The restrictions are strict. A table with a counter may contain only counters besides the primary key:
7
    CREATE TABLE post_counts (
      post_id uuid PRIMARY KEY,
      views counter,
      likes counter
    );                         -- ok
8
    ... title text, views counter ...   -- rejected
9
So counters live in their own table, separate from the data they count. That is usually the first surprise.
10
You also cannot set a counter to a value. No insert with a starting number, no reset to zero — only increment and decrement. To "reset", read the current value and subtract it, which is not atomic.
11
The part that matters most: retries are not safe. A normal Cassandra write is idempotent. Writing email = 'a@x.com' twice leaves the same state, so a client that times out can simply retry.
email = 'a@x.com'
12
An increment is not. If the write actually succeeded and the acknowledgement was lost, retrying adds one more:
13
    client sends +1  ->  replica applies it  ->  ack lost in the network
    client retries   ->  replica applies it again  ->  count is now 2
14
The count drifts upward by the number of ambiguous retries. So configure the driver not to retry counter writes automatically, and understand that counters are approximately right under failure, not exactly right.
15
Older Cassandra versions had worse problems than this and were substantially re-engineered in 2.1. Modern versions are reliable, but the retry issue is inherent — it is arithmetic, not a bug.
16
So use them where approximate is acceptable. View counts, like counts, metrics. Not for anything where the number is the truth: account balances, stock levels, or anything that must reconcile. Those want a ledger of events you can re-sum, or a lightweight transaction.
17
What the interviewer is probing.1. "What is special about a counter column?" Probing: the constraint. Stalls: "Nothing." Moves up: a counter table can contain only counters and the primary key, and counters cannot be set, only incremented.
18
2. "Why are counter writes not idempotent?" Probing: the consequence. Stalls: "They are." Moves up: an increment applied twice counts twice, so a retry after an uncertain timeout can over-count.
19
3. "What consistency do counters offer?" Probing: honesty. Stalls: "Strong." Moves up: they are eventually consistent and can be slightly wrong under failure — not suitable where exactness is required, like money.
20
4. "What is the performance characteristic?" Probing: the cost. Stalls: "Fast." Moves up: a counter write requires a read internally, so it is considerably more expensive than a normal write.
Use cases:countersdistributed-countingaggregate-metricsCQL