A number is a promise: counting honestly when a post goes viral.

Every piece of content we publish carries a small number beside it: how many people have seen it. It looks like decoration. It is not. That number is a promise, to the reader that the thing in front of them is as popular as we say, and to us that we understand what is actually happening across the app. A count that drifts is not a cosmetic bug. It is a quiet lie that compounds, because other things get built on top of it.

We spent part of this cycle making sure one of those numbers tells the truth, specifically at the moment truth is hardest to keep: when a post suddenly gets popular. The work was narrow. The lesson behind it is not, and it is worth writing down.

A small number is a promise

When traffic is calm, counting is trivial. Someone opens a post, and we record that a view happened. The displayed total ticks up by one. There is no pressure anywhere in the system, so the obvious approach works: let the app itself bump the total on the post each time, right there on the reader's device.

The trouble is that the obvious approach is tuned for the calm case, and the calm case is not the one that matters. The number matters most precisely when a post is being seen by thousands of people at once, which is also the exact situation the naive approach handles worst.

Where the naive approach breaks

A single record in a database can only be rewritten so many times per second before updates start to contend. When one post is quietly popular, nobody notices the ceiling. When a post goes viral, every viewer's device tries to edit the same record at the same instant, and those edits pile up against each other. Some are retried, some are dropped, and the headline total slowly peels away from the real number of views sitting in the underlying records.

The moment a thing becomes popular is the moment its number matters most. That is exactly the wrong moment for the number to start lying.

So we had a count that was accurate right up until the point anyone cared about it, and then silently wrong. That is the worst shape a metric can take, because it fails without an error. Nothing crashes. The number just stops being true, and it does so most dramatically for the content most people are looking at.

Record the event, compute the count

The fix was to stop conflating two different jobs that had been quietly glued together. Recording that a view happened, and reporting how many views there have been, are not the same operation, and they should not share a write path.

So we split them:

• The reader's device records, it does not tally. Each view writes one small, independent record of its own. Nothing competes, because no two viewers are editing the same thing. The write path is contention-free no matter how fast views arrive.
• The real count is computed, not accumulated. Instead of trusting a running total that many hands have touched, we ask the database a direct question: how many view records exist for this post? That answer is exact by construction, and it stays cheap whether the post has a hundred views or a hundred thousand.
• The headline total refreshes on a fixed cadence. A scheduled job recomputes the count for active posts and writes it back to the post on a steady rhythm. The cost of keeping the number current no longer scales with how viral the post is.
• Where accuracy matters most, we read the live answer. On the detailed view of a single post, we read the computed count directly and fall back to the cadenced total only if that read ever fails.

We also went back and reconciled the content that already existed, so that the number shown everywhere equals the number of records actually behind it. A correct design is not worth much if it starts from inherited bad data.

Why an honest count is the floor under a feed

This would be a tidy little story about one number, except that counts rarely stay private. The moment you decide to surface the most engaging content first, to rank a feed by what people are actually looking at, your ranking is only ever as honest as the counts underneath it. A feed built on numbers that drift under load does not just show a slightly wrong tally. It surfaces the wrong things, and it does so confidently.

That is why we treated accurate counting as foundational rather than cosmetic. A trending surface is a claim: these are the things worth your attention right now. We are not willing to make that claim on top of numbers we know go soft exactly when a post catches fire. Getting the count right is not polish applied after the interesting feature. It is the condition that lets the interesting feature be trustworthy at all.

The principle we keep

Strip away the specifics and the rule generalises well beyond one metric. Separate the act of recording that something happened from the act of reporting how much has happened. Keep the write path cheap, independent, and free of contention, so that popularity never becomes a bottleneck. Make the read path computed and exact, so the answer is derived from reality rather than from a figure many writers have nudged. And never let the cost of displaying a number scale with the number itself.

Most of the time nobody will notice this work, which is the point. The small number beside a post will simply be right, including on the day a post is seen more in an hour than it was in its whole life before. That is the kind of quiet correctness we would rather build once than apologise for later.