VI. Processes

Execute the app as one or more stateless processes

“Twelve-factor processes are stateless and share-nothing.” – 12factor.net

When to use

Designing architecture for scalability.

Why it matters

  • Scalability: If state is in memory, you can’t add more servers (load balance) because request #2 might hit Server B which doesn’t know about request #1.
  • Robustness: If a process crashes and restarts, no data is lost (because data is in the DB/Cache, not memory).

Signs of Violation

  • Storing session data in memory (req.session without a store).
  • Identifying users by “Sticky Sessions” on the load balancer.
  • Writing temp files to local disk and expecting them to remain for the next request.

Explanation

Problem

Stateful processes can’t scale easily.

Solution

Store state in a stateful backing service (Redis, Postgres). The app itself should be disposable code execution.

Real world analogy

A call center. It doesn’t matter which agent answers your call (Stateless Process). They look up your account in the computer (Stateful DB). You don’t need to talk to “Bob” specifically every time.

Pros and Cons

Pros Cons
  • Easy horizontal scaling
  • Simple restarts
    		•
  • Need external stores (Redis) for everything
    		•

    Comparison

    • Sticky Sessions: The anti-pattern to this.

    Code example

    Typescript

    Bad (Violation)

    Good (Adherence)

    PHP

    Bad (Violation)

    Good (Adherence)