In an inline login-risk scorer, what is a per-device velocity counter and why is it kept continuously updated?

## What a velocity counter is A **velocity counter** is the simplest useful feature on a risk-scoring path: the number of times something happened to **one entity** inside a **recent time window**. It is arithmetic, not modelling — nothing about it is learned, and the same counter can feed a model input, a rule, or an operations dashboard without changing meaning. On a consumer login path three counters carry most of the signal, and saying **which counter** you mean is load-bearing because they catch different attacks: | counter key | example feature | what it catches | |---|---|---| | per account | failed logins for this account in the last 5 minutes | someone guessing one victim's password | | per device | distinct accounts this device attempted in the last hour | one client replaying a stolen credential list | | per source network | attempts from this network address in the last minute | a single origin fanning out across many accounts | A bare "the velocity counter" is ambiguous in a design round, and the interviewer is usually listening for whether you name the entity key. ## Why it is maintained instead of computed The scorer runs **inside** the credential submit, before the session is granted, on a hard budget of a few tens of milliseconds. That budget is what rules out computing the count from raw events when the request arrives. | approach | cost at request time | behaviour under attack | |---|---|---| | scan this entity's event history | grows with how active the entity is | worst exactly when the entity is hostile | | read a maintained counter by key | one lookup, flat | unchanged by attack volume | The second row is the whole argument. An attacker is, by definition, the busiest entity in the system; a design whose read cost scales with activity gets slowest precisely on the requests that matter most. ## How it is kept up to date 1. Login and session events — attempt, success, failure, password reset, device first-seen — are published to an **event stream** as they happen. 2. A **stream processor** (or, for the shortest windows, the scoring service itself) folds each event into a counter in a **low-latency key-value store**, keyed by entity and window. 3. Each counter carries a **time-to-live** matched to its window, so an entity that goes quiet ages out of the store instead of being swept by a separate job. 4. The scorer reads the counters it needs by key, in parallel, inside the feature-fetch stage of its budget. ## What the window means - A counter with a TTL is an approximation of a **sliding window**: it forgets the whole window at once rather than attempt by attempt. - An exact sliding count needs the individual timestamps kept per entity, which costs more storage and a more expensive read — real systems pick per feature, and some keep both a short exact window and a long approximate one. - Long windows (24 hours, 30 days) describe an entity's **baseline**; short windows (60 seconds, 5 minutes) describe what it is doing **right now**. Most login scorers carry both, because the interesting signal is usually the ratio between them. ## What a velocity counter is not - **Not a decision.** A high count is an input; whether a login is allowed, challenged or declined is decided further down the path. - **Not a rule.** "More than 20 attempts in a minute" is a rule expressed over a counter, but the counter itself asserts nothing. - **Not unique to fraud.** The same maintained-count pattern shows up wherever a read must be cheap and the underlying event volume is unbounded; here it happens to be the cheapest risk signal there is. ## What it costs - **Read cost:** one lookup per entity key per scored request. Three keys means a fan-out of three, and the stage's latency is the **slowest** of them, not the sum. - **Storage:** roughly one entry per active entity per window, bounded by the TTL rather than by total history. - **Write cost:** one increment per event, off the request path when the stream processor owns it. - **A lag:** the value the scorer reads is as fresh as the pipeline that wrote it, which matters once an attacker moves faster than that pipeline. Because it is this cheap and this legible, a velocity counter is usually the first feature a risk system ships and the last one it would give up — a fraud team that loses its model can still run on counters, which is why they double as the degraded path when scoring fails.