Soft state

State may change over time, even without input

“The state of the system may change over time, even without application input, due to strict consistency not being enforced.”

Part of the BASE acronym.

When to use

Caching, session management, distributed counters.

Why it matters

  • Resources: Keeping state “Hard” (Permanent, Consistent) is expensive.
  • Maintenance: Systems can self-correct (e.g., refreshing a cache, expiring a session).

Signs of Violation

  • Expecting data read from a cache to remain there indefinitely.
  • Panicking because a “View Count” fluctuated down by 1.

Explanation

Problem

In ACID, state only changes when a transaction commits. In BASE, state is “fuzzy”. It might disappear (cache eviction) or update (background replication) without user action.

Solution

Design applications to handle uncertainty. Don’t rely on data being permanently fixed.

Real world analogy

A whiteboard. Whatever is written there is “Soft State”. Someone might erase it. It’s not carved in stone (Hard State).

Pros and Cons

Pros Cons
  • Performance
  • Memory efficiency
    		•
  • Unpredictability
    		•

    Comparison

    • Hard State: Data in a PostgreSQL table (usually).

    Code example

    Typescript

    Good (Adherence)

    PHP

    Good (Adherence)