Reindex API Version Conflicts: Reconciling Old-Index Writes Before Alias Cutover

Planning a zero-downtime index migration for a small Elasticsearch application using the Reindex API and an atomic alias cutover. The Reindex API aborts when source documents are updated during the job, and the conflicts parameter changes that behavior only by skipping conflicting documents, which silently drops those updates. An aliases API request can atomically remove the old index and add the new one, but writes that reach the old index during the reindex window are not automatically reconciled afterward.

The unresolved decision is how to handle that write window before the alias swap. Options include a brief write freeze, application-level dual writes, or a final delta reindex, each carrying different consistency and complexity tradeoffs for a small deployment. Because the Reindex API copies only documents and not settings or mappings, the destination index must be created up front with the intended configuration, and clients must address the alias rather than a concrete index name. Version-sensitive behavior around mapping types and remote reindex settings means the exact parameters must match the deployed Elasticsearch version.

For a small cluster, throttling the reindex with requests_per_second and running it asynchronously with wait_for_completion=false are standard resource controls, but they do not resolve the write-loss question. Which reconciliation strategy best preserves data integrity without introducing downtime for a small application? What verification steps confirm that no updates were lost before the alias is switched, and how should the reindex task be monitored to ensure the write window is fully accounted for?