StatefulSet vs Deployment: what's the difference?

WHAT THIS TESTS Whether you can pick the correct controller for a workload and articulate exactly which guarantees stateful systems depend on.

A GOOD ANSWER COVERS A Deployment is for stateless workloads. Its Pods are fungible, get random hash-suffixed names, are created and replaced in no guaranteed order, and typically share storage or have none. A StatefulSet is for workloads where identity matters. It gives each Pod a stable, predictable name based on an ordinal index, such as db-0 and db-1, that persists across rescheduling. Combined with a headless Service, each Pod gets a stable DNS hostname so peers can address each other reliably. Each Pod gets its own PersistentVolume created from a volumeClaimTemplate, and that volume stays bound to the same ordinal even if the Pod is rescheduled to another node, preserving per-replica data. Operations are ordered: Pods are created and scaled up sequentially from the lowest ordinal, and terminated in reverse, which lets clustered systems bootstrap and gracefully shrink safely.

COMMON WRONG ANSWERS Using a Deployment for a database and expecting stable names or per-Pod storage. Thinking StatefulSet Pods share one volume. Believing rollout order does not matter. Forgetting the headless Service requirement for stable network identity.

LIKELY FOLLOW-UPS How does the headless Service provide DNS identity? What does volumeClaimTemplates do? Why does ordered termination matter for a quorum-based database? When is a Deployment with a shared PVC still acceptable?

ONE CONCRETE EXAMPLE A three-node Cassandra cluster runs as a StatefulSet so Pods cassandra-0 through cassandra-2 keep stable hostnames and each retains its own data volume after a reschedule, whereas a stateless web frontend runs as a Deployment whose Pods can be replaced freely.