How Queues work

Before you start

• Databases

  Queues and partitions sit around a primary database. That lesson covers the key and the index.

  Open lesson

Why it matters

A click count is useful to the owner but irrelevant to the visitor waiting for a 301. Updating the same counter during every open adds a write to the hottest path, and a viral x7 can concentrate those writes on one row. Losing a small fraction of counts is acceptable; losing or delaying the redirect is not, so the 301 must not wait for a counter commit.

Every redirect may be counted, but the visitor’s 301 must not wait for the counter to commit.

Input

clicks = ["x7", "q2", "x7", "x7", "q2"], batch = 3

Output

[{"x7": 3, "q2": 2}, 2]

Instead of incrementing x7 before its 301, publish an x7 click event and let a worker combine [x7, q2, x7] into one batched update; visitor latency stays independent of the counter, at the cost of delayed counts.

After choosing the redirect for x7, the API emits a small click event containing x7 and, in production, an event id. A counter worker consumes independently, so a burst waits in the queue instead of extending visitor latency. The event may be best effort because the product permits a little undercounting.

The worker groups events such as [x7, q2, x7] and applies their totals in one database update. It records event ids or uses an idempotent aggregation key to avoid double-counting redelivery. Batching cuts writes, but the dashboard becomes eventually consistent when the worker falls behind.