Placement Group

Two clusters, two opposite requirements. A 16-node in-memory analytics cluster is bounded by inter-node bandwidth on every run. A 6-node quorum store must not lose a majority to a single hardware event. One placement policy cannot serve both, and the deciding question is the same for each: what do you lose when one rack fails?

For the analytics cluster the answer is a job, which you re-run. For the quorum store it is possibly the majority, which is an availability and correctness event no re-run fixes.

Placement groups express that choice to the provider:

• Cluster placement packs instances into one low-latency network segment. Lowest latency and jitter, highest sustained bandwidth, and a shared failure domain by construction.
• Spread placement puts each instance on distinct underlying hardware. AWS documents a limit of 7 running instances per availability zone per spread group, which signals the intent: small sets of individually critical instances.
• Partition placement divides the group into partitions, each on its own set of racks, and lets you map replicas onto partitions - designed for replicated data systems of a dozen nodes or more.

Why it matters

Availability-zone selection is the placement decision everyone makes, and inside a zone most teams assume the provider spreads instances sensibly. It usually does, and "usually" is not a property you can design a quorum around. Without a constraint, nothing prevents three of five members landing on the same rack, and nothing tells you that they have.

In the other direction, the cost of ignoring placement is paid continuously rather than during an incident: a tightly coupled job that is not placed closely runs slower on every execution, and the difference is measurable in a benchmark anyone can run.

Implementation patterns

• Spread for small, individually critical sets - quorum members, a pair of stateful primaries, a handful of brokers - and treat the per-zone instance limit as part of the design.
• Partition for replicated data systems, mapping replica sets onto partitions so that a rack event costs one replica per shard rather than a shard.
• Cluster only for tightly coupled compute where members are interchangeable and the work is recomputable, and understand that you have chosen a shared failure domain.
• Prefer availability zones first. Zones are stronger failure domains than racks and the placement question is secondary to them; for most services the honest answer is that zone distribution is the only placement decision that matters.
• Plan for launch failures. Cluster groups need contiguous capacity, so a group can fail to scale when the provider has none - keep an instance-type fallback and do not make a cluster group a hard dependency of autoscaling.

Industry example

AWS's documentation sets out the three strategies, the per-zone limit on spread groups, and the recommendation to launch all instances of a cluster group in a single request so that capacity is allocated together. The partition strategy exists explicitly because distributed data systems - HDFS, Cassandra, Kafka - need rack awareness, and their own rack-awareness features are only as good as the placement information they are given.

The useful cross-check is to compare it with what those systems do natively. Rack-aware replica placement inside Kafka or Cassandra is the same idea one layer up, and configuring one while ignoring the other is how a cluster ends up believing it has rack diversity it does not have. Note the scale of what is being traded: intra-zone placement moves latency by tens of microseconds, while cross-zone placement moves it by roughly 1 to 2 ms - so the zone decision dominates the rack decision by three orders of magnitude.

Failure scenarios

• A quorum packed into one rack, surviving every test and failing completely on a single switch event.
• Replicas co-located despite rack-aware software, because the application's rack labels do not correspond to the physical placement the provider chose.
• Cluster group launch failures when contiguous capacity is unavailable, which turns a placement preference into a scaling outage.
• Instance-type lock-in, where a group effectively fixes the family and a later upgrade requires rebuilding the group.
• False confidence from spread groups, used beyond the per-zone limit, where the extra instances are placed without the guarantee that was being relied on.

Trade-offs

When not to use it

When the bottleneck is not the network, which is most of the time. If a cluster is bounded by disk or by a remote dependency, cluster placement changes nothing measurable and adds a capacity constraint for free.

When the workload runs on a managed service, where placement is the provider's concern and is not exposed - the equivalent lever is multi-zone configuration.

And when availability zones already give you the independence you need: spreading six quorum members across three zones is a stronger guarantee than any intra-zone placement policy, and cross-zone latency, not rack locality, is then the number that matters.

Interview question

Q: You are deploying a 5-node consensus store and a 20-node Cassandra ring in one region. Specify the placement for each and tell me what you would check after launch to confirm you got what you asked for.

What a strong answer covers: zones first, as the dominant failure domain; spread placement for the consensus members, with the per-zone instance limit noted; partition placement for the ring with replica sets mapped onto partitions and the application's rack labels aligned to it; why cluster placement is wrong for both; verification by inspecting the actual placement and the application's own view of rack diversity rather than trusting the request; and the launch-failure risk that makes a cluster group a poor dependency for autoscaling.

Quick check

Quiz: Why is cluster placement the wrong choice for a quorum store even though it gives the lowest latency? Because it puts the members in one failure domain, so a single rack event can take the majority - and consensus gains almost nothing from the microseconds saved, which are dwarfed by its own durable write.

Flashcard: Which placement strategy fits a replicated data system of twenty nodes, and why not spread? Partition placement, because it gives rack-distinct groups you can map replicas onto - spread groups are limited to a handful of instances per zone and offer no mapping.