What does setting index.translog.durability to async cost you when an Elasticsearch node crashes?

## What the translog is for Each Elasticsearch shard keeps a **translog** — an append-only log of every indexing and delete operation. Its purpose is to close the gap between an acknowledged write and a Lucene commit. Segments are only fsynced at flush time, which happens relatively rarely; without a log, everything written since the last commit would vanish on a crash. On restart a shard opens its last Lucene commit and replays the translog forward to reach the acknowledged state. ## The durability setting `index.translog.durability` takes two values: - **`request`** (default): before responding to a write, the shard appends the operation to the translog and **fsyncs** it — and it does this on the primary *and* on every in-sync replica. An acknowledged write is therefore on stable storage in multiple places. - **`async`**: operations are appended to the translog and the response goes out immediately. The translog is fsynced on a timer, every `index.translog.sync_interval` (default `5s`). ## What you gain An fsync is a synchronous durability barrier on the storage device. Under a heavy bulk load, per-request fsyncs on every shard copy can dominate write latency, particularly on network-attached or spinning storage. Switching to `async` removes that barrier from the request path, batching many operations into one periodic sync. On fsync-bound hardware the throughput difference is large; on fast local NVMe it is often much smaller, which is worth measuring before accepting the risk. ## What you lose You lose the meaning of the acknowledgement. With `async`, a `200` response means "we have this in memory and in the page cache", not "this is on disk". If the machine loses power or the kernel panics, up to `sync_interval` worth of acknowledged writes is gone from that copy. Two refinements matter in an interview: 1. **Process crash versus machine crash.** If only the Elasticsearch process dies, unsynced translog data is still in the operating system's page cache and the OS will write it out; the shard recovers fine. The exposure is specifically to power loss, kernel panic, or a violent host termination. 2. **Replicas do not save you automatically.** With `async`, the replicas are also running async. A correlated failure — a rack losing power, a hypervisor host dying with several copies on it, an availability-zone outage — can take out every copy's unsynced window at once. Replication reduces the probability but does not turn `async` back into `request`. There is also a subtle behavioural point: if a shard is *removed and recovered*, and the operation was never fsynced anywhere, it simply never existed as far as the cluster is concerned. There is no reconciliation pass that notices a client was told "success". ## When it is a reasonable trade - **Reindexable data.** If Elasticsearch is a derived index over a relational database, an event log, or object storage, losing five seconds of writes costs a replay, not data. This is the canonical case. - **Observability and metrics pipelines.** Losing a few seconds of logs during a host power loss is usually tolerable, and these workloads are exactly the fsync-bound ones. - **Bulk backfills**, where you set it temporarily for the duration of the load and restore `request` afterwards. This is the safest use: the window of exposure is bounded and you can always re-run the load. ## When it is not - Elasticsearch is the system of record for the data. - The write is the acknowledgement a user or another system acts on — an order, a payment, an audit event. - Compliance requires that an acknowledged write is durable. In those cases keep `request` and buy throughput elsewhere: bigger bulk requests, more shards or nodes, faster storage, higher `refresh_interval`, fewer replicas during a load. ## Related knobs `index.translog.sync_interval` sets how often the async sync runs and therefore the size of the loss window. `index.translog.flush_threshold_size` governs when a flush commits segments and lets the translog be trimmed — that is about recovery time and disk usage, not about the acknowledgement guarantee. Both are dynamic index settings, so `async` can be turned on for a load and off again without recreating the index. ## How to present it A strong answer names the guarantee being sold — "acknowledged means fsynced on primary and in-sync replicas" — then says precisely what `async` replaces it with, the size of the window, the class of failure it exposes you to, and the workloads where that is an honest trade. Weak answers describe it as a general "performance setting" without naming the data loss.