The combination of IWID ordering (I1) and deterministic replay guarantees that any read after a write observes the latest value, even if the underlying shard has been reconstructed.
| System | Primary Goal | Ingestion Model | Indexing | Fault‑Tolerance | Exactly‑Once | |--------|--------------|-----------------|----------|-----------------|--------------| | Apache Kafka | Messaging | Partitioned log | None (external) | Replication (ISR) | Yes (idempotent producer) | | Apache Pulsar | Messaging + Storage | Segmented log + BookKeeper | No native index | Replication + BookKeeper | Yes | | Apache Flink State Backend (RocksDB) | Stream processing | Checkpointed state | LSM‑tree | Changelog + snapshots | Yes | | Amazon Kinesis Data Streams | Managed streaming | Sharded log | No index | Replication across AZ | Yes | | Google Cloud Bigtable | Wide‑column store | Tablet‑based writes | LSM‑tree | Replication + tablet recovery | No | | | Unified streaming storage | Hybrid LSM + log | Built‑in secondary indexes | Erasure‑coded shards + deterministic replay | Yes (IWIDs) | fsdss-825
Modern data‑intensive applications—online advertising platforms, autonomous‑vehicle fleets, and large‑scale scientific observatories—must ingest while supporting sub‑second analytical queries over recent and historical data. Conventional streaming platforms (Kafka, Pulsar) excel at append‑only log delivery but rely on external key‑value stores for random reads, leading to write amplification and coordinated checkpoint overheads. Conversely, distributed storage systems (Cassandra, HBase) provide random access but lack native support for exactly‑once stream semantics. The combination of IWID ordering (I1) and deterministic