Lesson 15 · Senior Kubernetes judgment

Stateful identity, storage, and when StatefulSet is a fit

How to reason about when a StatefulSet is truly justified, when it is a workaround for another design problem, and how this repo’s non-textbook usage still teaches the right senior lessons.

Your win: explain when StatefulSet is a real fit, when it may signal a design smell, and how to discuss the repo’s own usage honestly instead of pretending every StatefulSet is a textbook database case.

In plain English Plain English: StatefulSet is for workloads that truly need stable identity, ordering, or per-pod state — not for workloads that just feel important or complicated.

Why this page is worth lingering on

Many Kubernetes explanations make StatefulSet sound like “the serious workload object.” That is a bad instinct. StatefulSet is not “more production.” It is simply the right tool when the workload’s identity and lifecycle constraints are stronger than what a Deployment can model comfortably.

This is why the repo’s usage is such a good senior teaching case. The StatefulSets here are not the most textbook example: they are not primarily databases with the classic headless-service-plus-per-pod-PV story. Instead, they are used mainly for stable identity and ordered behavior. That matters because it teaches you to reason from required guarantees, not from cargo-cult patterns.

And that is the real tone shift from intermediate to senior thinking. You stop asking “which object sounds stronger?” and start asking “which guarantees does this workload actually need?”

The StatefulSet rule Reach for StatefulSet only when stable pod identity, ordered lifecycle, or per-pod state is genuinely part of the workload contract.

What the repo teaches well

In this repo, conversationmgmt and tom are the exceptions, not the rule. Most backend services are perfectly well modeled as Deployments. That contrast is powerful. It keeps the default honest: stateless clones should stay Deployments unless the workload really requires more.

It also creates a great senior review question: “What specific guarantee would break if this were converted to a Deployment?” If the answer is vague, the StatefulSet choice may be weak. If the answer clearly names stable identity, ordering, or per-instance coordination, the choice becomes easier to defend.

Backend use case In this repo, only conversationmgmt and tom invoke the shared StatefulSet path, while most other services remain on the standard Deployment path from libs/util/templates/_deployment.tpl.

Common mistake Choosing StatefulSet because the workload is “important” or because operators want stronger-sounding abstractions, instead of requiring a real stable-identity or per-pod-state contract.

What stronger answers sound like

The strongest answers here sound specific: “StatefulSet is justified when the workload contract needs stable identity, ordering, or per-pod state. In this repo, the key teaching point is that only two backend business services need that path, and even there the reasoning is more about stable identity than a textbook database pattern.”

That answer is stronger because it respects the actual guarantees instead of flattening everything into “StatefulSet means stateful app.”

How to get the most out of this page

When you review StatefulSet examples, keep forcing yourself to name the broken guarantee. If you cannot say what would fail under a Deployment, your argument probably is not strong enough yet.

Re-read the StatefulSet docs, then compare the repo’s deviations

Look at the official guarantees, then compare them to how the repo uses StatefulSets in practice.

→ Kubernetes — StatefulSets
→ Repo K8s map

Check yourself (from memory)

Q1. When is StatefulSet the right default choice?

StatefulSet is about required guarantees, not importance or status.

What is the strongest one-line test for whether a StatefulSet is justified?

recall, then click to reveal

Ask what specific guarantee would break if the workload became a Deployment. If the answer is stable identity, ordered lifecycle, or per-pod state, the StatefulSet case is stronger.

Want a “Deployment or StatefulSet?” design drill? Ask me.

Sources. Kubernetes StatefulSet docs; repo K8s map.