Solr Infrastructure for SAP Commerce: Topology, Sizing, and Tuning

Where your Solr runs, how many nodes it has, and how its JVM is sized determine the ceiling of everything the search guides in this series tune. This guide covers the infrastructure layer: the topology choice between Solr Cloud and a standalone cluster, the sizing arithmetic, and the configuration-level tuning that survives any topology.

A framing note for 2026: on CCv2, SAP provisions and operates the Solr layer (nodes plus ZooKeeper ensemble), pins the Solr version to your commerce update release, and takes the infrastructure decisions off your plate. What stays on your plate there is everything logical: indexer threading, commit strategy, shard and replica configuration where exposed, schema and solrconfig.xml customizations shipped via the manifest, and all query-side tuning. On-premise and self-hosted installations own the full stack below that too, and this guide covers both altitudes.

The Three Modes, One of Which You Should Never Use#

• Embedded: Solr inside the commerce JVM process. Development convenience only. In any performance environment a Solr crash takes the platform with it, and you can neither monitor nor scale the two independently.
• Standalone cluster: separate Solr JVMs in a primary/replica arrangement. The classic on-premise production setup.
• Solr Cloud: multiple nodes holding shards and replicas of collections, coordinated by ZooKeeper, which handles request routing, distributed indexing, query distribution, and node management. This is what CCv2 provisions.

Solr Cloud: Planning the Cluster#

ZooKeeper quorum#

ZooKeeper is the cluster's brain, and it needs a quorum to avoid split-brain: with N nodes, the ensemble survives as long as more than half are alive (quorum Q = (N+1)/2). That is why ensembles are odd-sized: three ZooKeeper nodes tolerate one failure, five tolerate two. Production ensembles belong on nodes separate from the Solr JVMs where availability requirements are real; development can run a single embedded ZooKeeper.

Shards and replicas#

Distributed indexing needs at least two shards; availability needs at least two copies of each. That makes four Solr nodes the practical minimum for a cloud that actually exploits being one, with fault tolerance following: tolerable failed nodes = round down(N/2) - 1.

Shard count and replication factor are set in the Backoffice indexer configuration when the collection is created. Two operational facts that surprise teams:

1. Changing the layout means recreating the collection. An existing collection keeps its geometry; to move from 2x1 to 3x2 you delete the collection (Solr admin) and run a full index, which recreates it with the new settings.
2. The platform enforces one shard (primary or replica) per live node. Request a 3-shard, replication-factor-2 layout on fewer than six nodes and collection creation fails with the explicit arithmetic:

Cannot create collection master_backoffice_backoffice_product_default.
Value of maxShardsPerNode is 1, and the number of nodes currently live ... is 3.
Value of numShards is 3 and value of replicationFactor is 2.
This requires 6 shards to be created (higher than the allowed number)

You can work around it (create 3x1, add replicas manually in the Solr admin), but the error is Solr telling you the honest answer: you want more geometry than you have nodes.

When Solr Cloud wins, and when it is overkill#

The honest cost side: Solr Cloud needs more servers (ZooKeeper plus per-shard redundancy), node roles are dynamic so operations differ from the static primary/replica world, distributed indexing failures need deliberate error-handling configuration, and a backup and restore strategy for collections is not optional. Function queries across shards also deserve testing: distributed scoring has edge cases, including distributed-deadlock risks under badly behaved queries.

Standalone Cluster: The Primary/Replica Discipline#

Where standalone is the right choice, one rule generates most of the value: the primary indexes, the replicas serve queries, and the primary serves no storefront traffic. The benefits compound:

1. Different Solr configurations per role: replicas get cache warming (firstSearcher listeners priming the caches before traffic arrives), the primary skips query-side machinery entirely.
2. Different JVM profiles per role (see sizing below).
3. Predictable latency both ways: query load never slows indexing, indexing never slows queries.
4. Failure isolation: a dead primary stops index updates but the site keeps searching on the last replicated index; a dead replica is just capacity, replaced by adding another.

The platform round-robins queries across configured replicas natively. For query loads beyond what one replication tier handles, replicas can themselves act as primaries for a second tier, giving multi-tiered replication for wide fan-out.

Configuration lives in Facet Search Config (Backoffice) and, for promotion across environments, in versioned ImpEx (the accelerator's solr.impex files are the template to copy).

Sizing Arithmetic#

The rules that have survived contact with many production installations:

• Memory: JVM heap = expected index size on disk + working memory for Solr itself, and the machine gets double the heap so the OS page cache can hold the index. Example: 4 GB index + 4 GB Solr working set = 8 GB heap on a 16 GB machine. Do not exceed 16 GB heap; beyond that, garbage collection pauses cost more than the extra caching gains.
• CPU: 2 to 4 cores minimum per node. In standalone clusters, primaries want the CPU (indexing is compute-heavy) and can run leaner memory; replicas want the memory (caches) and can run leaner CPU. In Solr Cloud, size all nodes identically because roles move.
• Disk: SSDs help indexing and are cheap enough that the question is obsolete; they are not strictly required.
• A baseline reference point: 2 to 4 cores and 8 to 16 GB RAM serves on the order of tens of millions of ~1 KB documents at ~10 queries per second with sub-half-second responses for small and medium queries. Treat it as a starting envelope to load-test against your own data, not a guarantee.

Indexer Settings That Dominate Everything Else#

Two platform-side settings routinely dwarf all infrastructure tuning:

1. Indexer threads: allocate generously (the indexing bottleneck on healthy hardware is usually thread starvation, not Solr).
2. Commit mode AFTER_INDEX, not AFTER_BATCH. Committing after every batch serializes the run on index commits; committing once at the end removes the bottleneck entirely. Combined with the two-phase strategy from the indexing guide, this is also operationally safe.

solrconfig and schema Tuning Worth Shipping#

These live in your repository's Solr customization and apply on CCv2 exactly as on-premise:

• filterCache first. Storefront traffic is dominated by repeated filter combinations (category, facets, catalog version); a well-sized filterCache is the single highest-yield cache setting. Push filters into fq clauses (not the main query) so they hit it; the query-tuning guide covers this from the query side.
• Display-only fields: indexed="false" stored="true". Fields the storefront renders but never searches or facets on should not occupy index memory.
• Stop words trim the indexed vocabulary; maintain them per language.
• Large indexes: switch NRTCachingDirectory to MMapDirectory in solrconfig.xml, disable the compound file system, and raise the open-files limit (15000 is the reference number) to match.
• Leading wildcards (*term) are a term-dictionary scan and degrade badly at scale. If the requirement is real, index with ReversedWildcardFilterFactory so the reversed form turns a leading wildcard into a trailing one; otherwise reject the requirement.
• Fuzzy search similarity: setting the threshold too low explodes candidate sets; keep it conservative.
• JVM: modern G1GC defaults are fine (old advice against G1 is obsolete). UseLargePages helps only when huge pages are actually configured correctly on the host; misconfigured, it triggers Solr's OOM scripts. Default startup heap (512 MB) is never right for production; set it per the sizing rules above.

Security: Solr Trusts Its Network, So Control the Network#

Solr's platform integration does not use Solr-level authentication, which makes network controls the whole story:

• Solr endpoints are never internet-exposed. External consumers (mobile apps, partners) go through OCC, which fronts search safely.
• Only application servers may reach Solr ports, enforced by firewall or security groups, with the Solr admin UI reachable only from an operations jump host.
• Lower-environment app servers must never be able to reach production Solr. This one has a nasty concrete failure: Solr connection configuration lives in the database, so restoring a production snapshot into staging leaves staging pointed at production Solr. If the network allows that connection, your staging full-index rebuild just destroyed the production index. Block it at the network layer, and make fixing the Solr config part of the documented restore procedure.
• ZooKeeper gets the same internal-only network treatment in Solr Cloud setups.
• Keep the Solr hosts' Java at the latest supported version; Solr CVEs are regular events.

On CCv2 the endpoint exposure side is handled through the portal's IP filter model (Solr endpoint: deny all, admin filter set only), which implements exactly this policy.

Decision Summary#

Infrastructure buys you the ceiling; the indexing and query guides in this series determine how close to it you actually run.