RisingWave Community - What is RisingWave's read after write consistency model and how often do S3 flushes occur?

By default, the result of processing data or an insert in RisingWave is not visible until the data has been flushed/committed to S3, providing a strong consistency guarantee.
S3 flushes occur based on user configuration, with a typical example being every 2.5 seconds (2500 ms) as calculated from the barrier interval and checkpoint frequency settings.
Users can adjust the frequency of S3 flushes by modifying the barrier interval or checkpoint frequency.
RisingWave typically expects latency in the range of 2 to 3 digits milliseconds, depending on the query's computational and I/O intensity.
Flushing too often may lead to the generation of many small L0 sstables, potentially increasing the workload for the compactor.
RisingWave's storage engine has sublevels in L0 similar to Pebble, reducing compaction work compared to other implementations.
Remote compaction in RisingWave helps distribute CPU-intensive compaction work to remote nodes or Lambda Functions, minimizing latency spikes and back pressure issues.
Users can query results that have not been checkpointed to S3, but there may be differences in results queried before and after recovery from failures.