Application Patterns
Most workloads on Kubernetes fall into a handful of recurring shapes, and each maps cleanly onto a specific set of objects. Recognizing the shape tells you which controller, networking, and storage choices fit — and which to avoid.
This is the step back from individual objects to how they assemble. Get the pattern right and the object choices follow; force a workload into the wrong pattern and you fight the platform.
The Stateless Web Tier
The most common shape: a stateless service behind a load balancer. It maps to a Deployment (interchangeable replicas), a Service and Ingress/Gateway for traffic, an HPA for load, and ConfigMaps/Secrets for config. State lives elsewhere — a managed database or cache — so any replica can serve any request and scaling is just more replicas. This is Kubernetes at its best, and most apps should be pushed toward it.
Asynchronous Workers
Work that arrives as messages on a queue is a different shape: a pool of workers (a Deployment) consuming from a queue, scaled by queue depth rather than CPU — which is where KEDA (Topic 27) shines, including scale-to-zero when the queue is empty. The web tier and the workers are separate Deployments connected by the queue, not crammed together, so each scales on its own signal. Decoupling request handling from background work this way is a core cloud-native pattern.
Stateful Backends
When state genuinely lives in the workload — a database, a clustered store — the shape is a StatefulSet with stable identity and per-Pod storage, usually run by an operator that handles backup and failover (Topics 14, 39). But the honest default remains: for most teams, a managed data service is the better answer than self-running state on Kubernetes. Reserve the stateful-on-Kubernetes pattern for when you have a real reason and the operational maturity to back it.
| Shape | Objects | Scales on |
|---|---|---|
| Stateless web | Deployment + Service + Ingress + HPA | Replicas (CPU/RPS) |
| Async workers | Deployment + queue (+ KEDA) | Queue depth |
| Stateful backend | StatefulSet + operator (or managed) | Carefully, with state |
| Batch / scheduled | Job / CronJob | Parallelism |
Twelve-Factor on Kubernetes
Underlying all the good shapes is the twelve-factor discipline: keep processes stateless and store state in backing services; take config from the environment (ConfigMaps/Secrets); treat logs as streams to stdout; and make processes disposable — fast to start, graceful to stop, safe to kill at any moment. Kubernetes rewards apps built this way and punishes those that aren't: a process that can't tolerate being rescheduled, or hides state on local disk, will fight the platform constantly.
Stateless — Deployment + external state; any replica serves any request; scale by replicas. The default to aim for.
Stateful — StatefulSet + operator (or managed); identity and storage per replica; scale carefully. Use only when state truly belongs in the workload.
- Forcing stateful behavior into a stateless Deployment (local-disk state, sticky assumptions).
- Running databases yourself by default instead of considering a managed service.
- Coupling the web tier and background workers into one workload so they can't scale independently.
- Ignoring graceful shutdown, so rescheduling drops in-flight work.
- Scaling async workers on CPU when queue depth is the real load signal.
- Push workloads toward the stateless web pattern; keep state in backing services.
- Separate request handling from background work via a queue; scale workers on queue depth.
- Use a managed data service unless you have a real reason and the maturity to self-run state.
- Build twelve-factor: env config, stdout logs, disposable processes that start fast and stop gracefully.
- Match the workload to its pattern's objects rather than bending one shape into another.
Knowledge Check
What objects implement the stateless web-tier pattern?
- Deployment + Service + Ingress/Gateway + HPA, with state in a backing service
- StatefulSet + headless Service + operator, with a PersistentVolumeClaim per replica
- DaemonSet + NodePort, one Pod pinned per node
- Job + CronJob driven by a schedule
What signal should asynchronous queue workers scale on?
- Queue depth (e.g. via KEDA), not CPU
- The current node count in the cluster autoscaler
- The total number of namespaces in the cluster
- The on-disk size of the etcd datastore
What does twelve-factor discipline give you on Kubernetes?
- Stateless, env-configured, disposable processes that the platform can reschedule freely
- Automatic, scheduled backups of your application database and its persistent volumes
- A service mesh installed and configured for free
- Guaranteed zero-downtime deploys even without readiness probes
You got correct