How does Lucene ensure durability and crash recovery?

Lucene's durability model is built entirely around the commit point concept rather than a separate write-ahead log layer - that additional layer (like a translog) is something systems built on Lucene, such as Elasticsearch, add themselves.

1. Each commit writes a new segments_N file only after all referenced segment files have been fsynced to disk, guaranteeing the data those segments reference is actually durable first.
2. The segments_N file write itself is atomic at the filesystem level (write-then-rename), so a reader never observes a half-written commit point.
3. An IndexDeletionPolicy decides how many past commit points to retain; by default only the most recent is kept, but retaining older ones enables point-in-time recovery or external backup strategies.
4. On startup, Lucene simply opens the most recent valid segments_N - any segment files written after the last successful commit but before a crash are just orphaned files, never referenced, and can be safely ignored or cleaned up.

The trade-off is that anything indexed after the last commit and not yet durable is lost on crash - which is exactly why systems needing stronger guarantees between commits, like Elasticsearch, layer their own translog on top rather than relying on Lucene's commit granularity alone.