Retail commerce as an engineering domain: the path from browsing a catalogue to a delivered parcel, and the places it gets genuinely hard, which are product data, search relevance, inventory consistency and the promotions engine.
Very high demand19 min readBackend engineer (commerce platform), Search and relevance engineer, Order management systems engineer, Solution architect (retail), Merchandiser, Pricing and promotions analystUpdated 2026-07-27
Assumes you know: REST APIs and relational data modelling, Basic distributed-systems vocabulary such as idempotency and eventual consistency
Overview
What this area actually covers
This domain is the rules and boundaries that turn a person looking at a screen
into a parcel on a doorstep: the product catalogue, search and browse, cart and
checkout, payment and tax, inventory and availability, order orchestration and
fulfilment, returns, and pricing and promotions. In a large retailer each of
those is a separate team with vocabulary stakeholders use without explaining.
What people wrongly bundle in is the storefront, which is close to a commodity
now. Interviewers here do not ask whether you can build a product page; they
ask why the price on that page might differ from the price in the cart, and who
decides which one wins.
Warehousing and last mile belong to logistics; card networks and settlement
belong to banking and payments. Commerce consumes both: it needs to know
whether a payment is authorised and a parcel can ship, not how the message
between banks is formatted.
The section has nine subsections, and they map almost exactly onto how a large
retailer organises its engineering. That is not a coincidence — the boundaries
exist because the failure modes are different, and a team that owns two of them
tends to be good at one. Read the tour before choosing where to start, because
the domain rewards depth in one area far more than a shallow pass over all
nine.
Catalogue & Product Data is the modelling of what you sell: products,
variants, category-specific attributes, taxonomy, and the enrichment process
that turns a supplier feed into something a customer can filter. It is first
because everything downstream reads it, and its defects are invisible — an item
with the wrong attributes is simply never found. Open it for variant
hierarchies, attribute modelling per category, identifier matching across
suppliers, and why product data quality is a revenue problem.
Search & Discovery covers relevance ranking, facets, merchandising
overrides and what happens when a query returns nothing. It is separate from
the catalogue because it is a projection with its own index, its own staleness
and its own success metric, which is conversion rather than correctness. Expect
analysers and synonyms, ranking signals in tension, merchandiser pinning rules,
and zero-result handling, which is where the easiest money in the domain often
is.
Cart & Checkout is the funnel: persisting a cart across devices and
sessions, orchestrating the checkout steps, calculating tax and shipping, and
failing gracefully in a place where every error costs a sale. It gets its own
area because the constraints are conversion-driven and the correctness bar is
unusually high for something that must also be fast. Read it for cart merge on
login, checkout orchestration, tax and shipping calculation, and the discipline
of handling a failure without losing the basket.
Inventory & Availability is the number that says whether you can sell
something, and it is the central consistency problem of the domain.
Reservations, the deliberate trade between overselling and lost sales,
availability across many locations, and the constant drift between what the
system believes and what is on the shelf. It is separate because it is the one
area where the source of truth is physical. Open it for the availability
calculation, reservation lifecycles, and reconciliation after a count.
Order Management & Fulfilment is what happens after the order exists:
deciding which location ships each line, splitting an order across shipments,
handling cancellations and backorders, and orchestrating the whole thing as a
long-running process across services that can each fail. It warrants its own
area because an order is a state machine with more branches than anything else
in commerce. Expect sourcing and allocation logic, partial shipment, and
saga-style orchestration.
Pricing & Promotions covers how a final price is arrived at: the price
hierarchy from list price down through channel, customer group and contract,
then promotion eligibility, stacking, coupons, and the ability to explain
afterwards why a basket cost what it did. It is separate because it is a rules
engine configured by non-engineers, and because auditability of a price is a
genuine requirement. Read it for price resolution order, stacking and exclusion
rules, and how to record which rules fired.
Payments & Fraud is the retail-side view of taking money: which methods you
offer, when you authorise and when you capture, split tender across gift card
and card, and the screening decision that trades fraud loss against declining
good customers. It is here rather than in banking because the trade-offs are
commercial — a false decline costs a customer, and nobody logs it as an
incident. Open it for authorisation timing, method-specific behaviour, and
fraud screening economics.
Returns & Reverse Logistics is the flow backwards: authorising a return,
receiving and grading the goods, refunding correctly, restocking or disposing,
and the accounting behind all of it. It is a first-class area rather than an
edge case because in some categories a very large share of what ships comes
back. Expect return authorisation, refund mechanics that are not simply the
inverse of payment, and the unwinding of promotions.
Marketplace & Omnichannel covers the two structural variants that change
the system rather than configure it: many sellers offering the same product,
and stores acting as fulfilment nodes. It is grouped because both break the
assumption that you own the stock and the customer relationship end to end.
Read it for the product-versus-offer split, seller payouts, click-and-collect,
and the dependency on store stock accuracy.
Subsection
What it is for
Catalogue & Product Data
Modelling what you sell so it can be found and matched
Search & Discovery
Ranking, faceting and merchandising the catalogue
Cart & Checkout
Getting from intent to a committed order without losing it
Inventory & Availability
Deciding what you can credibly promise
Order Management & Fulfilment
Sourcing, splitting and completing the order
Pricing & Promotions
Arriving at a final price you can explain
Payments & Fraud
Taking money, and deciding whom to refuse
Returns & Reverse Logistics
Unwinding goods, money and promotions
Marketplace & Omnichannel
Many sellers, and stores as fulfilment nodes
Where it sits in a real business
Goods and money move on different clocks through different systems of record,
and this domain exists to keep them reconciled. An order is a promise, not a
transaction: recorded before the money moves and long before the goods do.
Step
System of record
What is committed
Browse and search
Search index, projected from the catalogue
Nothing; the index may be stale
Add to cart
Cart service, short-lived
Nothing; price is a snapshot, stock a hint
Checkout
Order service
The order, plus an inventory reservation
Payment
Payment service provider
An authorisation, meaning a hold, not a payment
Allocation
Inventory or order management system
Which warehouse or store ships each line
Dispatch
Warehouse or store system
The physical pick, and the capture of funds
Delivery
Carrier
Completion, and the start of the returns window
Return
Returns and refunds
Reversal of goods, money, and any promotion applied
Money moves in two steps, authorisation at checkout and capture at dispatch,
because you should not take payment for goods you have not shipped. An
authorisation expires after a window set by the provider, so a delayed shipment
quietly becomes a failed capture, leaving a customer holding an order and a
retailer holding no money.
The checkout itself is a short choreography between four systems, none of which
can be rolled back by the others:
Loading diagram…
The interesting gap is between the fourth and sixth lines. If order creation
fails after the authorisation succeeds, you have taken a hold on a customer's
funds for an order that does not exist, and only a reconciliation job will ever
find it. This is why order creation carries an idempotency key and why the
reservation is held before the money rather than after.
The order is the long-lived object
Once created, the order outlives the session by weeks and accumulates state
that no single service owns. Modelling it as a status column is the mistake
that every commerce team makes once.
Loading diagram…
The state to design around is PartiallyShipped. One order can become three
shipments from three locations, each with its own carrier, its own capture and
its own returns window, which means "the order status" is a derived summary of
line-level states rather than a fact of its own.
Where the margin actually goes
It is worth knowing what the business is optimising, because it explains
requests that otherwise look arbitrary. Revenue is the price paid; margin is
what survives after cost of goods, the discount that was applied, payment
processing, the cost of shipping the parcel, and the cost of the proportion
that comes back. A promotion that lifts conversion and raises the return rate
can lose money while every dashboard turns green. This is why returns data,
promotion attribution and shipping cost per order end up in the same report,
and why engineers are asked to record the discount at line level long before
anyone explains that returns are the reason.
The words people use without explaining them
Commerce vocabulary is mostly plain English used in a narrow technical sense,
which is worse than jargon because it sounds as though you understood it.
Term
The narrow meaning
SKU
Your internal identifier for one sellable variant
GTIN
The globally allocated identity of a trade item
Variant
One buyable combination, such as blue in medium
ATP
Available to promise; what you can credibly sell right now
Reservation
Stock held for an in-flight cart or order, with an expiry
Allocation
Stock committed to a specific order from a specific node
Node
Any location that can hold or ship stock, store or warehouse
Sourcing
Choosing which node ships each line
Buy box
Which seller's offer is shown by default on a shared product
Split tender
One order paid with more than one payment method
Stacking
Whether two promotions may both apply to one basket
RMA
The authorisation that lets a customer send something back
Peak
The calendar-known traffic season everything is planned around
The pair that causes the most confusion is reservation and allocation. A
reservation is provisional and expires by itself; an allocation is a commitment
to ship specific stock from a specific place and is released only by an
explicit action. Systems that use one word for both end up unable to say
whether an abandoned basket is still holding the last unit.
Who does this work
Building is done by backend engineers organised along those boxes, and the
specialisation is real. A catalogue engineer works on attribute schemas,
variant hierarchies and supplier ingestion; a search engineer on analysers,
synonyms and ranking signals; a checkout engineer on idempotency keys and
payment webhooks; an order management engineer on state machines, and on the
fact that one order can split into three shipments with three partial refund
paths.
Alongside them are the people who specify and operate the system. A
merchandiser decides what appears where and expects to change it without a
deployment. A pricing analyst configures rules your engine executes, in
combinations you did not anticipate. Store staff are the ones who find the
system believes there are four units on the shelf when there is one.
Role
Builds or specifies
The question they ask you
Catalogue engineer
Builds
Why can this item not be filtered on size
Search engineer
Builds
Which signal caused this ranking
Order management engineer
Builds
What happens if one of three shipments fails
Merchandiser
Specifies
Can I change this without a release
Pricing analyst
Specifies
Why did these two promotions both apply
Customer operations
Operates
Where is this parcel and can I refund it now
The merchandiser deserves emphasis because the relationship with that role
defines the architecture more than any technology choice. Every commerce
platform ends up with a boundary between what is configured and what is
deployed, and the position of that boundary is the single most consequential
design decision in the domain. Put it too far towards code and the business
queues behind you; put it too far towards configuration and nobody can predict
what the system will do on Friday.
Demand, adoption and how that is changing
Demand is very high for an unglamorous reason: the number of organisations that
sell something is enormous, and nearly all now sell through more than one
channel. The employer base spans retailers, brands, marketplaces, grocers, the
platform vendors and the consultancies that integrate them.
The composition has shifted, though. Building a cart from scratch is rarely
funded now; platforms and providers cover it. What is funded is replatforming
from a monolithic suite towards composable services with a headless front end,
usually because merchandising changes were bottlenecked behind engineering
releases. What survives that shift is whatever is specific to the business:
availability across channels, order orchestration, promotion rules, search
relevance.
Two further pressures are regulatory rather than fashionable and no vendor
abstracts them away: strong customer authentication reshaped checkout for
anyone selling in Europe, and country-level tax and e-invoicing regimes reach
into pricing and order data. Tax deserves specific mention because engineers
underestimate it consistently. Whether tax is included in the displayed price
or added at checkout differs by market, the rate can depend on the customer's
address, the product's classification and the seller's obligations in that
jurisdiction, and in marketplace models the liability may sit with the platform
rather than the seller. None of that is a field you add late.
What makes it hard
Product data is an underrated modelling problem. A products table with a
price survives about a week. A t-shirt is one product with a size-and-colour
variant matrix, each with its own stock and barcode; attributes are
per-category, so a mattress and a laptop share almost no fields; suppliers send
the same item under different identifiers, so ingestion is a matching problem
rather than an insert. Poor product data loses money invisibly, because an item
nobody can filter for is not really for sale.
The identifier layer is worth learning properly because it is where matching
either works or does not. A GTIN is the globally allocated identity of a
trade item and is the closest thing to a shared key across organisations; a SKU
is your own internal stock-keeping identifier and means nothing outside your
walls; a manufacturer part number identifies the item to its maker and is
neither unique nor consistently formatted. Suppliers will send you some subset
of these, spelled differently, and expect you to work it out.
Search is a revenue system, not a lookup. Buyers who use the search box
arrive with intent, so ranking changes move money directly. Relevance has no
correct answer to compare against, only signals in tension: textual match,
margin, availability, and a merchandiser who wants one product pinned to the
top of one term. Experimentation is the only arbiter.
The most valuable and least glamorous piece of that work is the zero-result
query. A query returning nothing is a customer telling you exactly what they
wanted and being refused, and the causes are mundane — a synonym you do not
have, a spelling you do not correct, a category filter silently still applied,
a product you genuinely do not stock. Sorting the top hundred zero-result
queries by volume is usually the highest-return hour available to a new search
engineer.
Inventory is the central consistency problem, and it has no clean solution.
Oversell means accepting an order you cannot fulfil, costing a cancellation and
a refund; lost sales means refusing an order you could have fulfilled, costing
margin silently, which is why it never reaches an incident review. The
mechanisms are reservations that expire so an abandoned checkout returns stock,
buffers that deliberately understate fast-moving lines, and an availability
figure that is a projection rather than a stored number:
available_to_promise(sku, node) =
on_hand # counted physically, and often wrong
- reserved # held by in-flight carts and orders
- allocated_not_shipped # promised to another order
- safety_stock # deliberate buffer
+ inbound_within_horizon # receipts you are willing to sell against
on_hand is a claim about the physical world, and shrinkage, mis-picks, damage
and store tills reported every few minutes make it drift. Availability is
eventually consistent against a source of truth that is itself unreliable, so
the design question is where to put the buffer, how fast to reconcile after a
count, and which channel is told the pessimistic number.
Sourcing is an optimisation nobody tells you about. Once an order exists,
something has to decide which location ships each line, and the decision is not
obvious: the nearest node may not hold the whole order, splitting costs a
second parcel, a store fulfilment saves shipping but consumes stock a walk-in
customer might have bought, and a node that is already over capacity today will
miss the promised date.
Loading diagram…
The branch to sit with is the last one. A retailer would rather ship late from
one node than split into three parcels, right up until the promised date is at
risk, at which point the weighting inverts. Encoding that as tunable weights
rather than nested conditionals is what separates a system the business can
adjust from one it fights.
Promotions grow teeth. An engine starts as ten per cent off a category and
two years later evaluates stacking order, mutual exclusivity, priority between
overlapping campaigns, per-customer limits, and codes traded online faster than
you can revoke them. Once it is a rules engine, nobody can predict what a
configuration will do, so you need a simulator, an audit trail of which rules
fired, and the discount recorded per line rather than once per basket.
The line-level requirement is not a preference, and the reason is arithmetic:
Basket: 3 shirts at 20.00 each, promotion buy three pay for two
Basket-level discount: 60.00 - 20.00 = 40.00 charged, discount 20.00
Customer returns one shirt. Refund?
Naive: 20.00, leaving 2 shirts for 20.00 total, promotion still applied
Correct: unwind the promotion, 2 shirts now cost 40.00, refund 0.00
Only a line-level record of the discount lets you compute the second answer.
Returns are a first-class flow, not an edge case. In fashion especially a
large fraction of what ships comes back, and the return is where earlier
shortcuts collapse. A refund is not the reverse of a payment: it may be
partial, cross an expired authorisation, go to store credit, or carry different
tax treatment. There is also a fraud decision, because return abuse is a real
cost centre, and a grading step, because a returned item is not automatically
saleable again.
The three business models are different systems, not variants.
First-party retail
Marketplace
Omnichannel
Who owns the stock
You
Many sellers
You, across stores and depots
Catalogue shape
Product
Product plus competing offers
Product, with per-store stock
Money flow
One payout, to you
Split payment and seller settlement
One payout, many cost centres
Hardest part
Availability accuracy
Offer matching and payouts
Store stock accuracy
Returns
One policy
Per-seller policies
Any channel, any store
In first-party retail you own the stock: one seller, one price, one payout. A
marketplace separates the product from the offer, because many sellers list the
same item, which forces catalogue matching, buy-box selection, split payments,
seller settlement, and orders that fragment into several shipments with several
returns policies. Omnichannel makes the store a fulfilment node, giving
click-and-collect, ship-from-store and in-store returns of online orders, at
the price of depending on store stock accuracy and on staff following a process
on a busy Saturday.
Why study it
The strongest argument is transfer. Little of this is specific to shopping:
reservations, idempotent order creation, saga-style orchestration across
services that can each fail, projections allowed to be stale, and rules
non-engineers must configure are the shape of most transactional systems.
Learning them where the consequence is obvious, because a customer either got
the parcel or did not, makes them stick.
Retail also produces a distinctive culture around traffic spikes, because peak
is calendar-known and non-negotiable. That breeds habits you will not pick up
under steady load: load testing as a scheduled season, change freezes for weeks
around peak, waiting rooms that admit users at a controlled rate, and
degradation planned in advance, such as suppressing live stock counts and
personalisation to protect checkout. Knowing in September exactly which
features you will switch off in November, and having tested the system with
them off, is a discipline most domains never force on you.
Skip it if you want database or distributed-systems internals, because this
domain uses those systems rather than builds them, or if low-latency trading is
the goal. And if you dislike requirements that are ambiguous because a business
chose them, promotions will exhaust you.
Your first hour
Open one product page at a retailer with a wide catalogue and reverse-engineer
its data model on paper: what is the product, what is the variant, which
attributes belong to the category rather than the item, and what identifier
would match it against the same item from another supplier.
Then write the artefact. On one page, state the availability expression for
that item using the formula above, and beside it a reservation lifecycle:
created on entering checkout, confirmed on order placement, released on
abandonment or timeout, consumed on dispatch. Add three failure cases and
what your design does about each: two customers reserve the last unit in the
same second; an authorisation expires before the item ships; a store sells the
last unit over the counter thirty seconds after your site accepted an order for
it. There are no clean answers, and noticing that is the point.
For a second exercise, take the promotion arithmetic above and extend it. Write
three overlapping promotions — a category percentage, a basket threshold
amount, and a multi-buy — then work out by hand what a five-item basket costs
under two different orderings of those rules. Write down which ordering you
would ship and what you would tell a customer who asks why they did not get
both offers. The answer is a business decision, and being able to state it
crisply is the skill.
What this is not
It is not web development with a shopping theme; the interesting problems sit
behind the storefront, which is the part most likely to be replaced next year.
It is not logistics, which has its own depth in slotting and routing. And it is
not payments engineering: you will integrate a provider and reason about
authorisation, capture, refund and chargeback, but building rails, issuing and
settlement is another domain.
Knowing a commerce platform is also not the same as knowing the domain.
Platform familiarity is often what the advertisement names, but it expires;
reasoning about inventory consistency, order state and promotion unwinding is
what transfers to the next platform.
Nor is it a solved problem you can buy. Suites cover the standard shape of a
retailer well, which is exactly why the funded work is the part where a
business differs from the standard shape — the availability rule that reflects
how its stores actually operate, the promotion its merchants insist on, the
returns policy its category demands. That residue does not shrink as the
packages improve, because it is the reason the retailer exists.
Whether you oversell or lose sales is not a bug to be fixed but a business
decision to be made deliberately, and knowing that separates someone who has
worked in this domain from someone who has read about it.