Selling through several channels is straightforward until two of them sell the same thing. The moment stock is visible in more than one place, the question becomes: which system is right, and how does everyone else find out?
The usual answer is a synchronisation feature. Each channel keeps its own stock figure and a job runs periodically to line them up. It works most of the time, which is exactly the problem, because the failures are silent and the reconciliation is manual.
There is a better answer, and it is a design decision rather than a feature.
Decide where the truth lives
Availability should be stored in one place and computed, not copied. In the Bishops Emporium platform that Opsenium built and operates, the database is the only inventory authority. Every surface, including the counter till, the webstore, the staff admin and the channel adapters, reads and reserves stock against the same rows.
Availability is never held as a separate number. It is calculated live as quantity minus active holds, inside a row-level lock. A till sale and a web checkout cannot both claim the same one-off item, because both must convert a hold on the same row and the loser receives a conflict rather than an oversell. This is not a coding convention that a future change could break; it is a property of the data model.
Deal with the systems you do not control
External channels cannot join your database transaction. eBay and Etsy each hold their own copy of a listing and take orders against it; Google Shopping holds a copy of the catalogue for listing purposes. Each has to be told when something changes, and each is a different kind of channel.
The pattern that works is a transactional outbox. When the system of record changes, it writes the change and a message to other systems in the same transaction. A worker drains the outbox and delivers the messages. If a channel is unavailable, the message waits and retries with backoff. If it is up, the message is delivered and marked done. Either way, the database and the outbox cannot disagree, and the channel is brought back into agreement once it accepts the update.
In the Bishops platform every channel adapter rides the same outbox: a basket hold becomes an out-of-stock message, a release becomes in-stock, a sale withdraws the listing, a refund relists it. Nothing is sent and hoped for.
Reconcile anyway
A transactional outbox ensures that intended updates are durably recorded and retried. It does not guarantee that an external provider accepts or applies the update, which is why reconciliation remains necessary. A buyer can commit to an eBay listing and not pay; a provider can time out a request it actually processed.
So the platform also reconciles. Periodic workers compare channel orders and listings with the platform’s own records and correct drift in the platform’s favour: a paid marketplace order is booked, an unpaid one is cancelled on a clock, and a listing that should not exist is withdrawn. Reconciliation is not a repair tool. It is scheduled, routine and boring.
Make the failures visible
Every queue has a memory. Jobs are recorded before they run, attempts are counted, and a job that cannot complete is dead-lettered with a reason rather than dropped. That gives an operator something to look at, and it gives the support process something to explain.
The same principle applies to email, parcel tracking and payment sweeps: each is a row before it is an action, so a provider outage delays work rather than losing it.
What this buys
The shop sells the same one-off items at the counter, on its website and on marketplaces, and nobody reconciles stock by hand. If an external channel is unavailable, updates remain queued and are retried. The exception is visible to the operator, and reconciliation restores agreement when the provider becomes available. When something does go wrong, there is a record of what was attempted and why.
None of this is exotic. It is a set of well-understood patterns applied consistently, chosen because they make systems converge without anyone watching. The Bishops Emporium case study describes the platform they are part of.