Ad-Tech
Impression & click aggregation
Per-campaign impression, click and spend counters aggregated across bid/serve nodes in real time, exact for pacing and capping.
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 run a programmatic exchange, DSP, or SSP.
- You keep per-campaign / per-creative budget, pacing, and frequency counters.
- Hot campaigns contend, and stale counts mean overspend or over-serving.
The workload
- Per-campaign / creative / placement counters: impressions, clicks, conversions, spend.
- Updated concurrently across many bid and serve nodes.
- Budget pacing and frequency capping read the counts, so they must be exact.
- Events arrive out of order across the serving fleet.
Today — serialized behind a lock
Exact per-campaign counts under concurrent serving means a per-campaign lock / CAS — or accepting stale, approximate counts and eating the overspend / over-serve. Hot campaigns contend; the lock caps serve throughput at exactly peak traffic.
With ATOMiK — order-independent, lock-free
Serve nodes feed count deltas into a shared accumulator with no per-campaign lock. The count is order-independent and byte-identical, so pacing and capping decisions use an exact count regardless of which node served first.
- No per-campaign lock contention — hot campaigns don't serialize the serve path.
- Exact counts for budget pacing & frequency capping — no overspend from stale reads.
- Linear scaling with banks; serve throughput holds under traffic spikes.
- Serve nodes never coordinate — order of impressions is irrelevant.