Processes, port binding, and concurrency
Factors VI–VIII — stateless processes, self-binding ports, and scale out via process model.
VI. Processes
Run the app as one or more stateless processes. Sticky session memory and local disk as durable store break horizontal scale and crash recovery. Persist in backing services.
Share-nothing processes are easier to restart, move, and multiply.
VII. Port binding
Export services by binding to a port (or equivalent platform socket) — self-contained, not injected into a pre-existing app server as a privileged extension. Behind routers/Ingress today, the process still listens; the platform routes.
VIII. Concurrency
Scale out via the process model (more instances/replicas), not only bigger boxes. Different work types become different process roles (web, worker, scheduler) scaled independently.
Senior practice today
- Kubernetes replicas and separate Deployments for workers express VIII
- Sticky local state in Pods without a design is still a VI violation
- Sidecars do not excuse putting durable state on the container filesystem
Threads inside one process help utilization; they do not replace horizontal concurrency for availability.