How realtime works

How realtime works? #

Do you like to let your customer wait? #

A document written to Pizza is searchable the moment its write is acknowledged — there is no refresh, no near-real-time window, and nothing to tune to get there. This page walks the write path that makes that true.

The write path #

1. WAL first. The write is appended to the shard’s write-ahead log (a local file-based WAL by default; a Kafka-backed WAL is available). Durability follows wal.local.durability — strict fsyncs per append, batched (the default) group-commits by size and timeout, async skips the hot-path fsync entirely.
2. Mutable layer. The live documents are indexed into the shard’s in-memory mutable layer, which is itself searchable — this is what removes the refresh: reads see the mutable layer and the immutable segments in one snapshot, so the visibility point is the write’s acknowledgement.
3. Epoch freeze and build. When the active epoch crosses a size or ops threshold (wal.local.epoch_freeze_max_bytes / epoch_freeze_max_ops, runtime-tunable), it is frozen and built in the background into an immutable FIRE segment. The build does not gate reads or writes.
4. WAL purge. Once a segment is durably built (per wal.local.segment_durability), the WAL entries it supersedes are purged, bounded by the retention window (wal.local.retention_epoch / retention_bytes).

Recovery is the mirror image: on restart, a shard replays its WAL tail over its last durable segments, so acknowledged writes survive crashes. Restart replay and peer recovery are both bounded by node.recovery_concurrency.