Clarify durability semantics for SyncMode.SYNC

[suleymanbyzt]

Hi Chronicle team,

I am currently experimenting with Chronicle Queue and trying to understand the durability semantics.

Config (simplified):

this.queue = SingleChronicleQueueBuilder.binary(queuePath)
    .wireType(WireType.BINARY_LIGHT)
    .rollCycle(builder.rollCycle)
    .syncMode(builder.syncMode) // SyncMode.SYNC
    .blockSize(builder.blockSize)
    .build();

Question:
When using SyncMode.SYNC, if an append (e.g., appender.writeDocument…)
returns successfully and I ACK based on that,
does Chronicle Queue guarantee that the data will survive a sudden VM crash,
kernel panic, or power loss? In other words, is “successful append” itself
a durability boundary?

I also noticed that even with SyncMode.SYNC enabled, write performance is
extraordinarily high (hundreds of thousands of ops/sec).
This is surprising compared to typical fsync-based systems, where throughput
drops dramatically.

• Does this performance imply that Chronicle Queue is handling durability
  differently than a strict fsync-per-write model?
• Is there any trade-off between this speed and durability guarantees?

If the answer depends on environment (filesystem, controller caches, PLP, etc.),
what is the recommended practice for minimizing risk of data loss?

• Should SyncMode.SYNC be considered “best effort” and replication/quorum ACK
  still required for true safety?
• Are there Chronicle-level patterns (periodic sync events, batching, etc.)
  that you recommend for stricter guarantees?

Thanks!

[tgd]

Hi @suleymanbyzt thanks for reaching out

In other words, is “successful append” itself a durability boundary?

This is a reasonable boundary in many cases but will not be sufficient in case of an unexpected and ungraceful system crash. Our recommendation for extra comfort in this kind of scenario is Queue Enterprise replication - if you reach out to account-management@chronicle.software the team can provide with some more info on this.

[andrm]

I haven't tested with SyncMode.SYNC but my general opinion is: It might be true for local attached disks, it won't be on a VM with EBS/Ceph like storage at all.