Retail & E-commerce
A catalogue, a checkout and one stock number that stays correct while traffic, promotions and supplier feeds all move at once.
The context
A storefront is the visible part. Underneath it, one order record takes writes from stock, pricing, promotions, payment and fulfilment, each arriving at a different speed. Under ZATCA e-invoicing that record also produces a regulated document, not a receipt the application prints.
What makes it hard
Load that arrives on a known date
Ramadan, White Friday and a two-hour flash sale put the heaviest traffic of the year through one checkout path. The page is rarely what breaks — the contention is on the stock row, where two customers buy the last unit.
One stock number, several channels
The storefront, the marketplace listing, the warehouse and the store counter read the same quantity, and none of them owns it. Whether a cart reserves stock or only allocates it at payment decides how often a confirmed order is cancelled.
Dirty data from supplier feeds
Supplier feeds bring duplicate SKUs, missing attributes and variants that are the same product written two ways. Arabic search has to match a name with and without diacritics, and under more than one accepted spelling.
The return as a second document
A return changes an order that has already been cleared, so a credit note becomes a reported document of its own. Refund logic that lives in the payment provider rather than the order record leaves finance and operations reading different numbers.
How we help
- The order record is designed before the storefront. Its shape is decided by what an invoice, a credit note and a fulfilment event carry, not by what a product page displays.
- Stock, payment callbacks and order state are treated as concurrent writes from the first design: reservations with an expiry, idempotency keys on every callback and one owner for the quantity. Oversell is then a decision, not an incident.
- ZATCA e-invoicing, the payment mix and the national address format are named as constraints in the first architecture review. A field added for clearance after launch is a migration through live orders.
- Arabic is not a translation layer. The catalogue is bilingual in the data model, because a product name, a search entry and an invoice line read the same field.
- Peak is rehearsed before the season rather than during it. That means load on the checkout path, cache misses under a promotion, and a payment provider that answers slowly.
- ZATCA Phase Two clearance for standard invoices, reporting for simplified ones
- Apple Pay, mada and instalment providers in one checkout
- VAT-inclusive prices that hold from listing to refund
- Saudi national address data and handover to the courier
- PDPL obligations on customer, order and address records
- Arabic and English catalogue, search and invoice output in one content model
Related services
Tell us what you are building.
Send the outline and we will come back with an honest read on scope, sequence and what it takes to run it in production.