Delta-state algebra vs the tools you already know.
Honest trade-offs so you can pick the right tool for the job.
Redis, etcd, and ZooKeeper are production-grade data stores with rich ecosystems. ATOMiK is not a replacement for any of them. It solves a narrower problem: synchronizing state across nodes with minimal bandwidth and zero coordination. Where these tools store and serve full key-value pairs, ATOMiK transmits only the XOR delta of what changed, and reconstructs the current state in O(1) from a single accumulator.
| Feature | ATOMiK | Redis | etcd | ZooKeeper |
|---|---|---|---|---|
| Consistency model | Convergent (Abelian group) | Eventual / strong (configurable) | Linearizable (Raft) | Linearizable (ZAB) |
| Sync bandwidth | O(delta) — XOR of changes only | Full key-value per write | Full key-value per write | Full znode per write |
| Coordination needed | None — order-independent | Leader for writes (Cluster) | Leader election required | Leader election required |
| Write latency | Deterministic, constant-time | Sub-ms (single node), variable (cluster) | ~10ms (Raft consensus round) | ~10ms (ZAB proposal round) |
| State reconstruction | O(1) — initial ⊕ accumulator | O(1) key lookup (stored in memory) | O(1) key lookup (stored in memory) | O(1) znode read (stored in memory) |
| Formal proofs | 92 Lean4 theorems | No formal verification | TLA+ spec (partial) | No formal verification |
Kafka and event sourcing give you ordered, replayable event logs with rich consumer ecosystems. CRDTs give you conflict-free convergence. ATOMiK overlaps with CRDTs conceptually (both converge without coordination), but uses a stricter algebraic structure (Abelian group vs. join-semilattice) that also provides free undo via self-inverse deltas. The trade-off: ATOMiK does not store individual events and has no concept of consumer groups or partitions.
| Feature | ATOMiK | Kafka | Event Sourcing | CRDTs |
|---|---|---|---|---|
| Storage growth | Constant (single accumulator) | Linear (log retention) | Linear (event log) | Proportional to state size |
| Replay cost | O(1) — no replay needed | O(n) — scan from offset | O(n) — replay all events | O(1) — merge states directly |
| Undo / rollback | Re-apply same delta (self-inverse) | Produce compensating event | Produce compensating event | Not generally supported |
| Conflict resolution | Automatic (commutativity) | Partition-based ordering | Application-level logic | Automatic (join-semilattice) |
| Bandwidth per update | Size of changed fields only | Full message payload | Full event payload | State or op payload (varies) |
| Ordering requirement | None — commutative + associative | Total order per partition | Total order per aggregate | None (op-based) / causal (state-based) |
Traditional change detection scans the full content (checksums, diff) or walks a tree (Merkle). ATOMiK detects changes in O(1) by checking whether the accumulator equals the identity element. On FPGA, this is a single-cycle comparison. The deterministic, constant-time execution also eliminates timing side channels that affect hash-based approaches.
| Feature | ATOMiK | Checksums (SHA/MD5) | Diff / Patch | Merkle Trees |
|---|---|---|---|---|
| Detection complexity | O(1) — compare accumulator to identity | O(n) — hash full content | O(n) — byte-by-byte comparison | O(log n) — walk tree path |
| Per-page cost | Single XOR (1 cycle on FPGA) | Full hash computation | Full content scan | Hash per node on path |
| False negative rate | Zero (algebraically proven) | Negligible (collision probability) | Zero | Negligible (collision probability) |
| Deterministic timing | Yes — constant-time, no branches | No — data-dependent | No — data-dependent | Partially — fixed-depth trees only |
| Side channels | None — no speculative execution | Timing varies with input | Timing varies with differences | Path-dependent timing |
GPUs excel at massively parallel floating-point work (ML, graphics). ASICs deliver the highest performance per watt for a fixed function. ATOMiK targets FPGA because delta-state operations are simple, wide, and embarrassingly parallel—a natural fit for configurable fabric. A $13.50 Tang Nano 9K runs the full stack. A Zynq-7020 reaches 69.7 Gops/s with 512 parallel banks at under 1W.
| Feature | ATOMiK FPGA | GPU Computing | ASIC (custom) |
|---|---|---|---|
| Operations/sec | 69.7 Gops/s (512 banks, Zynq) | Tera-scale (matrix ops) | Application-specific, highest |
| Dev board cost | $13.50 (Tang Nano 9K) | $200+ (entry-level) | $100K+ (tape-out) |
| Power consumption | < 1W (FPGA fabric) | 75–350W (typical GPU) | Lowest for given task |
| Formal verification | 92 Lean4 theorems + RTL sim | Numerical verification only | Full verification possible |
| Time to prototype | Hours (parameterized RTL) | Days (CUDA/OpenCL) | 12–18 months (fab cycle) |
Not a database
ATOMiK has no query language, no indexes, no transactions. If you need to store and query structured data, use PostgreSQL, Redis, or DynamoDB.
Not a message queue
ATOMiK does not provide ordered delivery, consumer groups, or dead-letter queues. If you need reliable message routing, use Kafka, RabbitMQ, or SQS.
Not cryptographic hashing
XOR-based accumulation is not collision-resistant in a cryptographic sense. Do not use ATOMiK as a substitute for SHA-256 in security contexts.
No built-in audit trail
Delta-state algebra accumulates changes into a single value. Individual deltas are not stored. If you need a full event history, use event sourcing or an append-only log.
Not for rich data transformations
ATOMiK tracks whether state changed and what the current state is. It does not map, filter, aggregate, or join data. Use Flink, Spark, or Kafka Streams for stream processing pipelines.
ATOMiK is open source (Apache 2.0). Install the Python SDK in seconds, or read the docs to understand the algebra first.