E-commerce and Retail

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 nine areas underneath

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.

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.

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:

sequenceDiagram
    participant S as Shopper
    participant C as Checkout
    participant I as Inventory
    participant O as Order service
    participant P as Payment provider
    S->>C: Place order
    C->>I: Reserve the lines
    I-->>C: Reservation held
    C->>P: Authorise the amount
    P-->>C: Approved
    C->>O: Create order, idempotent
    O-->>S: Confirmation
    C->>I: Convert reservation to allocation

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.

stateDiagram-v2
    [*] --> Placed
    Placed --> Allocated
    Placed --> Cancelled
    Allocated --> PartiallyShipped
    Allocated --> Shipped
    PartiallyShipped --> Shipped
    Shipped --> Delivered
    Delivered --> Returned
    Returned --> Refunded

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.

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.

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.

flowchart TD
    A[Order lines] --> B[Find nodes with stock]
    B --> C{Single node covers all}
    C -->|Yes| D[Allocate whole order]
    C -->|No| E[Score split options]
    E --> F[Weigh parcels against distance]
    F --> G{Meets promised date}
    G -->|Yes| H[Allocate the split]
    G -->|No| I[Backorder or cancel line]

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.

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.