Risk & Fraud
Real-time per-entity counters
Per-IP / per-user / per-card event counters for fraud and rate-limit decisions, exact under concurrency.
Measured 2026-06-21 on ALINX/HamGeek AX7020 (XC7Z020-2CLG484); reproduce with abench 65537 0xDEADBEEF0BADF00D. Throughput is the engine's accumulation rate (the aggregation step); end-to-end depends on your ingest path, which ATOMiK's order-independence frees from global ordering / locks.
This is you if
- You keep per-entity counters for fraud, abuse, or rate-limiting.
- Hot keys contend on your counter store under attack / traffic spikes.
- You need exact counts for allow / deny / challenge — not approximate.
The workload
- Per-entity (IP, user, card, device) event counters over sliding windows.
- Updated concurrently from many edge nodes / PoPs.
- A threshold decision reads the count, so it must be exact.
- Out-of-order and retried events from lossy edges.
Today — serialized behind a lock
Exact per-key counts under concurrent edge updates means a distributed lock / CAS or a serialized hot path per key. Hot keys (a botnet IP, a viral user) contend; the lock caps throughput and adds tail latency exactly when the decision needs to be fastest.
With ATOMiK — order-independent, lock-free
Edge nodes feed count deltas into a shared accumulator with no per-key lock. The count is order-independent and byte-identical, so the threshold decision is made on an exact value regardless of which node's events landed first.
- No per-key (hot-key) lock contention — the botnet-IP hot path doesn't serialize.
- Linear scaling with banks; decisions stay fast under spikes.
- Exact, byte-identical counts for thresholding under reordering.
- Edges never coordinate or sequence — order is irrelevant.