[Dylan16807]

> user-personalization, feature-gating > what features are shown when you load the home page, dictated by how many times these have been shown before for a given device

I don't see how any of those would suffer if the numbers took seconds to update instead of milliseconds.

We're talking about having updated numbers in milliseconds, right? Not just "the database responds in a reasonable amount of time" because that's been solved many many times over and the article specifically says "this category requires near-immediate access to the current count at low latencies".

> some initial use cases related to interactive titles

Maybe 1 second of latency for a group interaction? That's still orders of magnitude more slack. And I'd expect only moderate accuracy requirements.

[rshrin]

For the Eventually Consistent counter, the low millisecond requirement is for reads and writes, not for the convergence of counts. For this category, the convergence is in the order of seconds (user-personalization, feature-gating fall in this category). For the "Best-effort" category, there are some use cases that run experiments in a single-region and need access to current counts at low latencies (they basically add increments and read the value back in the same call i.e. AddAndGet), but are willing to sacrifice "some degree" of accuracy for it. See the table in the 2nd section. There are multiple dimensions in terms of Read/Write Latency, Staleness, Global reads/writes etc. mapped to the two kinds of use cases. Maybe you are conflating a few things. Finally, there is the experimental type of Accurate counters that can get the current count with high degree of accuracy (but the latency there depends on a few things as explained in the article). The last type is more like what can be done using this approach, no current use case for it.