A 16-node in-memory analytics cluster needs the lowest possible inter-node latency. A separate 6-node quorum store needs maximum independence between members. Which placement choice fits the pair?
Show the full answer Hide the answer
The deciding property
What you lose when one rack fails. For the analytics cluster the answer is "a job, which you re-run": the work is recomputable and inter-node bandwidth is the constraint on every run. For the quorum store the answer is "possibly the majority", which is a correctness and availability event that no amount of re-running fixes.
Those two answers point in opposite directions, which is why one policy for both is wrong.
The three placement strategies
- Cluster placement packs instances close together in one network segment - lowest latency, highest sustained bandwidth, lowest jitter, and a shared failure domain by construction. It is the right choice when the workload is a tightly coupled computation whose members are interchangeable.
- Spread placement puts each instance on distinct underlying hardware, maximising independence. AWS documents a limit of 7 running instances per availability zone per spread group, which is a hint about the intended use: small sets of critical, individually important instances.
- Partition placement divides the group into partitions, each on its own set of racks, and lets you map replicas to partitions. It is designed for replicated data systems - a Cassandra-style ring or an HDFS cluster - where you want many nodes and want to know that two replicas are not on the same rack.
Why the other options fail
- "Cluster for both, consensus likes low latency." Consensus does benefit from low latency, and it benefits far more from not losing a majority at once. Packing 6 quorum members into one rack means a single rack event takes the store down, and the latency gain is measured in tens of microseconds that no consensus protocol notices against its fsync.
- "Spread for both." Beyond the per-zone instance limit, this is simply the wrong objective for a 16-node analytics job: independence buys nothing when the workload is a single job, and the lost bandwidth is paid on every run.
- "Partition for both." Partition placement is the right answer for a replicated data system of a dozen or more nodes - and for a 6-member quorum it is more machinery than a spread group, while for a tightly coupled compute cluster it deliberately gives up the locality you wanted.
What would flip the decision
| If this changes | Choose | Because |
|---|---|---|
| The analytics cluster becomes long-lived and stateful | partition placement | a rack event should cost one partition - not the cluster |
| The quorum store grows past 7 members per zone | partition placement - or spread across zones | the spread-group limit is a hard constraint |
| Members sit in different availability zones already | no group needed | zones are already distinct failure domains - and cross-zone latency dominates |
| The workload moves to a managed service | nothing to choose | placement is the provider's concern and is not exposed |
When this is the wrong level to optimise
If the cluster's bottleneck is disk or a remote dependency rather than inter-node network, placement changes nothing measurable - and placement groups constrain capacity, so a cluster group can fail to launch when the provider has no contiguous capacity. Measure the network's contribution first: for most services the honest answer is that availability zones are the only placement decision that matters.