The 30 second answer
A segment is an immutable mini index written once. Lucene never edits it: an update writes a new version of the document into a new segment and marks the old one deleted in the live-documents bitset. Searches read every segment and skip deleted documents. Background merges combine small segments into larger ones and drop deleted documents, which costs I/O and CPU.
Immutability. Elasticsearch's near-real-time page says that in Lucene, "index" means "a collection of segments plus a commit point", and that a segment is similar to an inverted index. New documents are buffered in memory and written out as a new segment.
Updates and deletes. Because segments are not modified:
- Delete: mark the document as deleted. Lucene keeps a live-documents file per segment; queries skip deleted documents.
- Update: delete plus add. The new version goes into a new segment; the old version stays on disk until a merge removes it.
Merges. Many small segments mean more files and more per-segment work per query. A merge policy combines segments of similar size into larger ones in the background, and only then reclaims the space of deleted documents. Merging competes with indexing and search for I/O and CPU, which is why heavy update traffic, such as constant price and stock changes, costs more than the document count suggests.
Why immutability is worth it. Readers need no locks, segment files can stay in the operating system's page cache because they never change, compression can be aggressive, and caches per segment remain valid until the segment is merged away. Introduction to Information Retrieval describes the same idea as a main index plus small auxiliary indexes merged over time.
Practical consequences. Avoid updating the same document many times a second; collapse updates per SKU before indexing. Prefer partial updates only when they save network, since Elasticsearch still reindexes the whole document internally. Force-merge only indices that no longer receive writes.