Explain the execution flow of an atomic update in Solr?

An atomic update lets you modify one or more fields of an existing document (e.g. change a "price" field) without resending the entire document. Under the hood, Lucene has no concept of in-place field updates on a document, so Solr has to simulate one.

1. The leader locates the existing document by its unique key and retrieves its current field values, which requires those fields to be either stored or use docValues - fields that are indexed but neither stored nor docValues-enabled are silently lost on atomic update.
2. The requested operation (set, add, inc, remove) is applied in memory to build a complete, updated version of the document.
3. The old version of the document is marked as deleted (soft-deleted, not physically removed yet) in the index.
4. The full merged document is reindexed as a brand-new Lucene document with an incremented internal version number.

Because this is really a delete-and-reinsert under the hood rather than a true partial write, atomic updates on large documents or high-frequency counters can be more expensive than they look, and a narrower field-only update pattern (like a separate collection for frequently changing counters) is sometimes used to avoid reindexing large static content on every small change.