How would you decide between one application-wide store and many small independent stores, in a long-lived application?

## The question behind the question "One store or many" sounds like a question about file layout. It is not. Every genuine difference between the shapes comes from three things: which changes must be **atomic**, which subscribers must be **woken**, and which instances must be **isolated**. Decide those and the layout follows. Decide the layout first and you spend a year arguing about consequences. ## The axes | Axis | One store | Many small stores | |---|---|---| | Cross-field invariants | one action, one notification, never observed half-applied | two writes, and a subscriber can read the gap | | Notification granularity | every subscriber woken per write; narrowness comes from selectors | a subscription wakes for one concern by construction | | Instancing and tests | one factory, one thing to create per request or test | many small things, each trivial to create and dispose | | Discoverability | one place to look and one action vocabulary | blast radius is obvious, location less so | | Coupling | easy for one feature to read another's fields | a cross-feature read is an explicit edge | | Derived state | derivations sit inside one applier | derived stores form a dependency graph | | Migration cost | large, hard to stage | incremental, one feature at a time | ## When one store earns it - Fields carry **invariants that span them** — a selection that must be cleared when the list it points into is replaced, a total that must match its line items. One applier makes that one step, so no subscriber ever reads the inconsistent pair. - You need to answer **"what changed this, and in what order"** for the whole application from a single ordered log. - You want exactly **one thing to create and provide** per request or per test. ## When many small stores earn it - The concerns are genuinely **independent**, so nothing about one constrains another. - Subscriptions should be narrow **by construction** rather than by everyone remembering to write a careful selector. - Features are **owned by different teams** and should not reach into each other's fields casually. - Pieces need **independent lifetimes** — created with a screen, discarded with it. ## The middle shape, which is usually the answer One store **assembled from independently defined slices**, each owning its write surface and its own invariants, instantiated once per request or test. You keep a single thing to create and provide, one ordered change log, and atomicity available when a change spans slices; subscriptions stay narrow because each slice is selected separately. The failure mode to watch is a slice reaching directly into another slice's fields — the coupling the many-stores shape prevents structurally and this shape can only prevent by review. ## What to measure before proposing a move 1. **Subscriptions woken per interaction.** Instrument the notification path and count listeners that ran against listeners that actually scheduled an update. A high woken-but-no-op ratio is a selector problem, and consolidating stores will not fix it. 2. **How often a change spans slices.** If nearly every action touches one area, atomicity is buying little. If a third of them span two, the split is costing correctness. 3. **Write sites per slice.** Many scattered writers to the same slice argue for a named write surface, whichever shape holds it. 4. **What breaks in tests.** Order-dependent failures point at shared instances, which is a packaging problem neither shape fixes by itself. Numbers matter here because both shapes have loud advocates and most of the published arguments are aesthetic. ## Failure modes at the extremes - **One store, no selector discipline:** everything selects broadly, every write wakes everything, and the team reaches for ever-wider comparisons instead of narrower selections. - **One store, no boundaries:** features read each other's fields until the store is the coupling surface nobody can refactor. - **Many stores, shared invariants:** values that must agree live apart, and the product grows defensive code for states that should have been impossible. - **Many stores, deep derivation:** derived stores read derived stores, ordering becomes observable, and eventually a cycle appears. ## How to stage a migration Keep both alive for a while. Define slices with their own write surfaces inside whichever container you are moving toward, move one feature at a time behind its slice's surface, keep exactly one instance per request so no component can see two sources of truth, and re-measure after each move. Stop when the numbers stop improving: the goal was never the shape, it was atomicity where invariants demand it and narrow notification everywhere else.