How does etcd compute the revision number in an atomic and scalable fashion?

[arjunsingri]

Just wondering how etcd computes the revision number that is monotonically increasing but is also able to support a high write throughput.

[jingyih]

I'm afraid I do not have a short or complete answer for this.

To answer the first half of the question regarding revision number:
To ensure linearizability guarantee, all mutating requests, once agreed by majority of servers in a cluster (via Raft consensus protocol), are applied sequentially to the key value store. Every mutating request increases the revision of store by 1.

The second half question involves optimization in many layers in the system. For example, starting from v3.2, mutating requests are batched: #7105. Starting from v3.4, long running reads do not block other requests including writes: #10523. etc.

[jingyih]

Closing this for now. Feel free to reopen if there are further questions.