I kept hearing the word state everywhere.
UI state.
Server state.
Stateful architecture.
Stateless APIs.
I nodded.
I Googled.
I moved on.
But deep down, I couldn’t explain what state actually meant in simple words.
This article is the mental model I wish I had earlier.
A simple definition
The state of a system is the information that describes what the system looks like right now.
Another way to say it:
State is what a system remembers in order to keep working correctly.
If the system forgot this information, it would not know where it is or what to do next.
That’s it.
State = memory.
A real-world analogy
Imagine a small coffee shop.
Behind the counter, there is a notebook:
Who ordered coffee
What they ordered
Who already paid
Which drink is being prepared
That notebook is the state of the coffee shop.
If you delete the notebook:
Baristas forget all orders
Customers need to repeat themselves
Chaos ensues
The shop still exists.
The employees still exist.
But without memory, the system collapses.
State vs behavior
It helped me to separate two things:
Behavior → what the system does
State → what the system remembers
Example:
A function that adds two numbers → behavior
A variable storing a number → state
Behavior is logic.
State is data.
Most software systems are:
Behavior + State
System state flow (diagram)
Here’s a simple flow that shows how state moves in a typical application:
This diagram shows:
A user interacts with the UI (which keeps UI state).
The UI calls an API.
The API reads/writes server state in a database.
The API responds back to the UI.
UI state
UI state is everything the interface remembers to display correctly.
Examples:
Is a modal open?
What is written in an input field?
Which tab is selected?
Is the page loading?
In pseudo-code:
isModalOpen = true
usernameInput = "alex"
selectedTab = "profile"
isLoading = false
This data lives in memory (usually in the browser).
If you refresh the page and everything resets, that’s because:
→ UI state was lost.
UI state describes how things look.
Server state
Server state is data stored on the backend.
Examples:
Users
Password hashes
Orders
Products
Permissions
Example:
User {
id: 42
email: alex@gmail.com
plan: "pro"
}
This data lives in databases or persistent storage.
If the server restarts and the database still contains the data, the state survives.
Server state describes what is true.
Client state vs server state
A useful mental model:
UI / Client State
Temporary
Lives in memory
Specific to one user
Controls appearance
Server State
Persistent
Stored in database
Shared across users
Source of truth
Short version:
UI state = how it looks
Server state = what exists
Stateful vs stateless systems
This part confused me a lot at first.
Let’s look at a simple comparison diagram:
In this visualization:
Stateful means the server remembers something about the client from request to request (for example, session data in memory or in a session store).
Stateless means each request contains all the information needed (e.g., a token), and the server does not retain client-specific session memory.
Stateful system
A stateful server remembers information about the client between requests.
Example:
You log in
Server stores your session in memory
Next request → server recognizes you
Server keeps client-specific memory.
Stateless system
In a stateless system, the server does not store client-specific state between requests.
Each request contains everything needed.
Example with JWT:
Client sends token
Token contains user info
Server verifies token
No session stored
Important:
Stateless does not mean “no state”.
The system still has state:
Users exist
Orders exist
Data exists
But the server does not remember client sessions.
Think:
Stateless = server has no memory about the client, not no memory at all.
Why engineers care so much about state
Because state creates complexity.
Bugs often come from incorrect state
Race conditions are state problems
Sync issues are state problems
Scaling issues are often state problems
A strong sentence:
Most hard bugs are state bugs.
Learning to identify state early makes systems easier to reason about.
My mental model today
Today I think about systems like this:
State = memory
Behavior = logic
System = memory + logic
Or:
If something can change over time and affect behavior → it’s state.
Once I adopted this model, many buzzwords started making sense.
Final thought
State is not a mystical concept.
It’s simply:
Data
That can change
And that the system depends on
Different layers hold different kinds of state.
Understanding that was a small shift.
But it unlocked a lot.
Sources & References
To deepen your understanding of state and stateful vs stateless concepts, here are a few solid references you can explore:
🧠 System State (General Definition)
- Wikipedia — State: explanation of system state as “remembered information that determines the current status of a system.”
🌐 Stateless vs Stateful Systems
Red Hat — Stateful vs Stateless Applications: a clear overview of what makes an application stateful or stateless, including context retention and session behavior.
RESTful API Statelessness (RESTfulAPI.net): explanation of how statelessness is defined in REST APIs — each request must contain all necessary state information.
These sources help ground the general ideas discussed here and give you authoritative, industry-recognized perspectives.