Data and State

Every useful application remembers things: a shopping cart remembers which items you added, a game remembers your score, a chat app remembers your conversation history. The information an application holds at any given moment — and how that information changes in response to events — is called state. Understanding state is not a back-end concern or a database concern. It is a fundamental design concern that touches every layer of your system.

What State Is and Where It Lives

State is any information that can change over time as a result of user actions or system events. A simple counter whose value increases when a button is clicked has state: the current count. A user's logged-in status is state. The list of items in a search result is state — it changes every time the user types a different query. State can live in several places, each with different properties: In-memory state (also called ephemeral state or transient state) exists only as long as a process is running. The state of a JavaScript variable in your browser tab disappears when the tab closes. This is appropriate for state that should not persist: the current position of a menu being dragged, a loading indicator, or the text the user is currently typing before they submit it. Client state is in-memory state managed on the user's device (the browser or mobile app). It is fast to access and does not require a network call, but it is private to that device and session. If a user opens your app on a different device, client state is not available there. Server state is managed by the back end and typically persisted in a database. It is available across devices, across sessions, and to multiple users simultaneously. A user's saved preferences, purchase history, or social connections must be server state. Cached state is a local copy of server state, kept on the client to avoid redundant network requests. Caching introduces a synchronization problem: the cached copy may become stale if the server data changes. Managing cache invalidation — deciding when a cached copy is outdated and must be refreshed — is one of the genuinely hard problems in software architecture. Example: In a social media app, the count of unread notifications is server state (it must reflect messages sent by other users). The current animation frame of a loading spinner is in-memory client state. A list of friends you have already fetched might be cached client state.

Data flow describes the path state takes as it moves through your system. In a typical web application, data flows in a cycle: a user action on the client sends a request to the server; the server reads or writes the database; the server returns a response; the client updates its local state and re-renders the view. A crucial discipline in data flow design is one-directional data flow: state should flow in one direction, from a single source of truth through the layers of the system to the view. When multiple components can simultaneously mutate shared state without coordination, the result is race conditions — situations where the outcome depends on which mutation arrives first. Race conditions produce bugs that are notoriously hard to reproduce and diagnose. A practical design rule: for any piece of state, identify exactly one owner — the component or layer responsible for holding the authoritative version of that state. Other components may read a copy, but only the owner may write. This is the principle behind patterns like Redux in front-end frameworks and event sourcing in distributed systems. Data modeling is the practice of deciding what data your application needs and how to structure it. Before writing a database schema or designing API responses, answer these questions for each major entity in your system: What attributes does it have? How does it relate to other entities? Who can create, read, update, or delete it, and under what conditions?

Designing Your Data Model

A data model is a formal description of the entities your application manages, their attributes, and the relationships between them. For a relational database, the data model is expressed as tables, columns, and foreign keys. For a document database, it is expressed as document schemas. For a front-end state manager, it is the shape of the central state object. Building a data model starts with entity identification — the same noun-extraction technique used in component design. For a school assignment tracker: entities include Student, Assignment, Course, and Submission. Each entity gets a set of attributes: Assignment has a title, a due date, a point value, and a course it belongs to. Submission has a student, an assignment, a submitted-at timestamp, a score, and a status. Relationships between entities fall into three categories: one-to-one (each student has exactly one user account), one-to-many (each course has many assignments), and many-to-many (each student is enrolled in many courses, and each course has many students). Many-to-many relationships require a join entity — in this case, an Enrollment entity that links a student to a course and records the enrollment date and grade. Security intersects data modeling at permissions. Every read and write operation should be governed by a rule specifying who is allowed to perform it. Can a student read another student's submission? Can a teacher modify an assignment after submissions have been received? These questions must be answered at the design stage, not discovered after a user exploits a gap.