A storefront and the double-entry ERP behind it, built as two deliberately separate systems.
LIVE · PUBLIC STOREFRONT
VIOR.COM.BD221 ms → 4 ms
Server response time
15 → 390
Requests per second
45
Database tables in the ERP
THE STOREFRONT, LIVE ON VIOR.COM.BD
THE PROBLEM
An online-first fashion brand needs two things that are usually bought separately and never quite fit: a storefront that sells, and a back office that knows what was sold, what it cost, what is owed and what is left in stock.
The usual shape is a hosted storefront plus accounting software, with a person in the middle retyping numbers from one into the other. That person is the single point of failure, and their mistakes surface weeks later as books that will not reconcile.
We wanted one truth. Orders placed in the store had to become journal entries without anyone retyping them, stock had to move in both systems at once, and the courier's delivery confirmation had to settle the payment and close the loop by itself.
WHAT WE BUILT
SHAPE OF IT
The store and the ERP are separate repositories, databases, cache instances, runtimes and service units. The only runtime link is a localhost API call for synchronisation. If the ERP is down, the store keeps selling — which is the whole point of separating them. Traffic arrives through a CDN, hits nginx, and is served by a prerendered storefront that in the common case touches neither the commerce API nor the database.
DECISIONS THAT MATTERED
Business owners do not think in debits and credits, and asking them to means the books are wrong within a month. Instead they post business documents — a bill, a payment, a production run — and balanced journals are generated from registered posting rules that reference accounts by semantic role rather than by ID. Adding a new kind of document means adding a rule file, not touching the ledger engine.
A CHECK constraint on the journal line table rejects any row that is both a debit and a credit, or negative in either. A partial unique index guarantees exactly one account per semantic role. These are the two things that make role-based posting safe, and putting them in the schema means no application bug — present or future — can write books that do not balance.
Corrections are written as mirrored reversal entries linked to the original, never as edits or deletes. An entry can be reversed exactly once, and a reversal cannot itself be reversed. Subledgers — supplier dues, customer dues, cash balances — are derived from posted journals rather than stored, so there is no cached balance that can silently drift out of agreement with the ledger.
Orders are pulled from the store every thirty seconds. The loop holds a re-entrancy lock, never throws, is idempotent by order ID, and pages backwards until it reaches a page it already knows. That last detail matters: a naive implementation that reads only the first page permanently loses any order pushed past it during an outage. This one recovers from an outage of any length without intervention.
The storefront originally rendered every page dynamically, because a single session-cookie read opted the entire render tree out of static generation. Worse, each anonymous visit minted a session the render could not persist — two database writes per pageview, for visitors who never bought anything. Splitting reads into a session-free catalog path and a session-carrying shopper path fixed both at once.
Every ad click carries a unique tracking parameter, which lands in the CDN cache key — so paid traffic ran at a zero per cent cache hit rate while organic traffic sat at a hundred. A URL rewrite that runs before the cache lookup normalises the key without touching the visitor's address bar, so attribution still works and the edge absorbs the spike.
If the ERP is down, the store keeps selling. That is the whole reason they are separate systems.
WHERE IT LANDED