What is the effect of fsync on Kafka performance and when should you configure it?

By default Kafka does not call fsync after every write. The docs recommend the default flush settings, which disable application-level fsync entirely and rely on the OS background flush plus Kafka's own background flush. Data is written to the filesystem immediately; the flush policy only controls when it is forced out of the OS cache (page cache) onto disk. Kafka does not need disk syncs for durability, because a failed node recovers from its replicas, and the docs say the guarantees provided by replication are stronger than a sync to the local disk. If you do want application-level flushing, flush.messages (flush after N messages) and flush.ms (maximum time a message stays in memory) can be set per topic, or log.flush.interval.messages and log.flush.interval.ms on the broker, but the docs note it is less efficient in disk usage, can add latency, and gives the OS less freedom to reorder writes; the topic config docs recommend not setting flush.messages and using replication for durability. Durability then comes from the replication settings: replication factor, acks and min.insync.replicas.

Expected key concepts: fsync, default flush settings, OS cache, background flush, replication, flush.messages, flush.ms, recovers from its replicas, min.insync.replicas