How do you choose Elasticsearch shard and replica counts?

Question

IT Interview Practice · Accepted Answer

Choose primary shards to divide data and work; choose replicas to provide additional copies and search capacity. Start from workload and recovery needs rather than a universal shard count.

## Calculate a first estimate

Suppose primary index data is 120 GB and testing suggests approximately 30 GB per primary shard works for your workload:

```text
120 GB / 30 GB = 4 primary shards
1 replica per primary = 4 additional shard copies
Total = 8 shard copies, roughly 240 GB of shard data
```

These are hypothetical sizing inputs. The storage estimate excludes growth and operating space for activities such as segment merges, which combine index files in the background.

## Why not keep adding shards?

More shards can spread work across nodes, but each adds management overhead and searches may fan out to more places. Larger shards reduce that overhead but can take longer to recover or move. Replicas add redundancy but also storage and write work; they are not backups.

## Test the failure case too

Measure peak reads and writes together, then test losing a node. Remaining nodes need enough disk, memory and processing capacity to recover within your target. For growing time-based data, rollover creates a new index when a chosen condition is reached, helping bound index size. These decisions apply to deployments where shard settings are user-managed.

[Official documentation](https://www.elastic.co/docs/deploy-manage/production-guidance/optimize-performance/size-shards).

Calculate a first estimate

Why not keep adding shards?

Test the failure case too

Related questions