Explain how Lucene's architecture influences distributed search systems like Solr and Elasticsearch?

Lucene's segment-based, immutable-write model turns out to map remarkably cleanly onto distributed systems concepts, which is a big part of why both Solr and Elasticsearch were built directly on top of it rather than writing their own indexing engine.

Because each Lucene index is already self-contained and independent, it's a natural unit of horizontal scaling: Elasticsearch's shards and Solr's cores/shards are each just one Lucene index, so scaling out means running more independent Lucene instances rather than redesigning the indexing engine itself. Replication follows the same logic - a replica shard is simply another Lucene index kept in sync with its primary, often by shipping the same indexing operations to both.

The immutable-segment model also fits distributed replication well: since segments are never modified in place, replicating an index (or shipping incremental segment files to a replica) is a matter of copying whole, unchanging files rather than reconciling in-place edits, which simplifies consistency compared to a mutable on-disk structure.

What Elasticsearch and Solr add on top - cluster coordination, request routing across shards, result merging from multiple nodes, and a translog for stronger durability between Lucene commits - is precisely the layer Lucene deliberately leaves out, since it's designed as an embeddable library rather than a distributed system in its own right.