We started with two Ozon stores. We now operate five. The interesting part of that change was not the number. It was discovering how many assumptions two stores let us keep.
With two stores, it is possible to hold the whole picture in one person's head. Which listing belongs to which store, which price belongs to which channel, and what happens when both stores try to sell the last unit are all answerable by memory. That stops working at three, and it fails loudly at five.
Store isolation is a boundary, not a copy
The first instinct when adding a store is to duplicate. Copy the catalogue, copy the stock numbers, copy the mapping table, change the store identifier. It looks fast, and it creates a second version of the truth that will disagree with the first one within a week.
We took the opposite position:
- Principle
- What it means in practice
- Store is an identity, not a stock bucket
- A store owns listings, prices, and channel rules — not its own inventory ledger
- Listing is a channel artefact
- Two stores may list the same physical product under different listing identities
- Product identity is shared
- The thing being sold is described once and referenced everywhere
- Stock is observed, never copied
- A store reports what it sees; the system records the observation instead of inventing a balance
Adding a store now adds a channel identity. It does not add inventory.
Why "observed inventory" instead of a per-store balance
Marketplaces tell you things at their own speed and in their own vocabulary. One channel reports sellable quantity after its own reservations. Another reports what it was told last night. Neither number is wrong, and neither number is the whole truth about the physical goods.
So we stopped asking each channel to be the source of a balance. A channel reports an observation: this is what I can see, from this source, at this time. Observations are recorded, compared, and reconciled — they are not silently merged into a single number that nobody can audit.
That one modelling decision is what makes five stores tractable instead of five times the maintenance.
What we had to build to make it hold
Running five storefronts under one operating model required three things that were not obvious at two:
- A single product identity that listings point at, so the same physical item is not re-described per channel.
- A mapping layer between marketplace listing identities and our own SKUs, because a seller article and an internal identifier are not the same thing.
- A resolver that answers "which channels can sell this, and at what price" without letting any single channel overwrite the shared record.
None of this is exotic. All of it has to be enforced, because the failure mode is silent: a duplicated stock number still looks like a valid number.
The cost of multi-store is not the fifth store. It is the second copy of the truth that you did not notice you created.
What changes as stores are added
With isolation held at the channel boundary, adding a store becomes an operational task instead of a data-migration project. The next store can go live with its own listing set, its own pricing rules, and its own reporting — while the products and the physical stock they reference stay where they were.
That is the property we were actually buying when we built the model. Not more stores. Fewer surprises per store.