Engineer the Concept

The cart works in memory; the application exits; the cart disappears. Should it survive? Persistence levels, the API the browser calls, where the code should live, the frontend, failure handling, and V0 → V6 with a reason for every stage.

The Cart Disappears

The cart works in memory; the application exits; the cart is gone. Whether it should survive is a requirement question, not a storage question — and answering it is what makes persistence a database problem you can now go and learn.

Q · The cart works and then the process exits and it is gone. Should it survive — and how do you decide before choosing where to keep it?
The Persistence Ladder
▶ lab

Anonymous only? One device? Survive a reload? Sync across devices? Logged in? Each answer is a rung: in memory, browser storage, server memory, database. Every rung exists to satisfy a requirement the rung below cannot, and costs something the rung below did not.

Q · Once the cart must survive, where should it live — and how do you choose a rung by requirement rather than by how serious the project feels?
From Cart.addItem() to POST /cart/items

The cart lives on the server; the browser cannot call a function in another process. Each operation becomes a request: the operation's inputs are the body, its output is the response, its errors are status codes, and its rules are re-checked because the browser cannot be trusted. API Design is one link away.

Q · The cart works as five functions on the server. How does a browser ask for addItem — and how do you derive the endpoints from the operations instead of inventing them?
Where Should This Code Live?
▶ lab

Frontend, backend, database or shared library — the cart's five functions and five rules can live in any of them, and the reflex puts them wherever the current file is. Authority, security, persistence, reuse and latency decide, and the same rule often lives in two places for two different reasons.

Q · The cart's logic exists once. Should it run in the browser, on the server, in the database, or in a library all three import — and what decides, other than where you happen to be typing?
The UI Holds a Copy

The cart moved to the server; the page still has to show it. The UI keeps a copy in component state, calls the API on every button, and replaces the copy with the response — the server's cart is the truth and the UI's is a cache. Optimistic updates come later, with a rollback rule.

Q · The cart lives on the server and the page has an Add button. What does the button do, what does the page hold, and which of the two carts is the real one?
What Can Go Wrong With a Cart

In memory nothing could go wrong that the rules did not catch. Persisted and shared, four new failures arrive: two tabs race on the same product, a product is removed from the catalog while in a cart, the price changes between add and checkout, and storage holds a cart from a previous world. Each one is a decision, not a bug.

Q · The cart works and is persisted. Which failures did persistence and sharing introduce that the in-memory cart could not have — and what does each one need you to decide?
V0 to V6, With a Reason for Each
▶ lab

Pure logic, then in memory, then the browser, then the server, then logged-in sync, then inventory validation, then high scale. Every stage exists because a requirement arrived, and every stage breaks an assumption the previous one made. A stage without a requirement is complexity without a reason.

Q · The cart could be built as V6 from the start. Why build V0 through V5 first — and how do you know when a stage is due, rather than merely possible?