The path from browse to delivered and back again, where inventory is the central consistency problem and every edge case is a real order belonging to a real person.
14 published across 9 topics.
E-commerce and retail fundamentals58 short answers on one page, for revising rather than studying.Product modelling, variants, attributes, taxonomy and enrichment.
Separate the product a customer shops for from the variant that carries a barcode and stock, decide which attributes are variant-defining rather than merely descriptive, and hold the rest in a typed per-category schema, because a fixed column set cannot grow and an untyped bag cannot be trusted.
You cannot know without matching, and matching is the work: suppliers send their own identifiers, spell the same manufacturer three ways, and describe attributes in units you do not use. Treat ingestion as a matching problem with a confidence threshold and a review queue, not as an import.
Relevance, facets, ranking signals, merchandising rules and zero-result handling.
Segment the query log first, then blend textual match with behavioural and business signals into a ranking you can explain, treat synonyms and merchandising overrides as owned content with expiry, and handle zero results as a designed page - while guarding against the click feedback loop.
With the zero-result queries, sorted by volume. Each one is a customer stating exactly what they wanted and being refused, the causes are mundane and fixable, and it is the only part of relevance work where you know for certain the current behaviour is wrong.
Cart persistence, checkout orchestration, tax and shipping, and conversion-critical failure handling.
Persist the order in a pending state before you touch the payment gateway, quote tax and shipping per seller shipment, authorise once behind an idempotency key, and commit the remaining steps through a transactional outbox and a saga whose compensations void the authorisation and release reserved stock.
You have two carts and no rule that is right for every case, so the merge has to be a deliberate product decision rather than whichever write lands last. Prices and stock have both moved since the older cart was created, which is the part that turns a session problem into a correctness one.
Reservations, oversell versus lost sales, multi-location availability and physical drift.
Treat availability as a claim you grant, not a number you read: fold the check and the decrement into one conditional write, hold the winner's claim as a reservation that expires, and choose deliberately how much overselling you accept, because the warehouse and not the database is the real source of truth.
Order orchestration, sourcing and allocation, partial shipment and cancellation.
Allocation is a cost minimisation over shipping, split-parcel cost and delivery promise, evaluated per line rather than per order; the design that survives is one where every line carries its own state, cancellation is a race against the pick face, and a shortfall is a normal outcome with a defined path.
Price hierarchies, promotion eligibility and stacking, coupons, and auditing a final price.
Only if it recorded which rules fired, in what order, against which lines, at the moment of the order. Recomputing today gives a different answer because prices and campaigns have moved, so the price becomes unexplainable exactly when someone needs it explained.
Model eligibility, exclusivity, and priority as explicit promotion data rather than accumulated conditionals, pin a deterministic evaluation order because the same two discounts applied in a different sequence produce a different total, and persist a price trace finance can read months later.
Payment methods, authorisation timing, split payments, and fraud screening trade-offs.
Authorise at checkout and capture when the goods leave, because an authorisation is a reversible hold and a capture is a refund waiting to happen; then set the fraud threshold from the full cost of a decline against the full cost of a chargeback, which usually means accepting more fraud than instinct suggests.
Return authorisation, refunds, restocking and the accounting behind it.
Not simply the item price to the original card. The discount attributed to that line has to be unwound, tax recalculated, the split tender apportioned, and the original authorisation may have expired - which is why refunds are a separate money movement rather than a reversal of the payment.
A return is its own order running backwards, with authorisation, a transport leg, an inspection that decides disposition, and a refund whose timing trades trust against exposure - and whose amount must come from what the customer paid after order-level discounts, not the line's list price.
Multi-seller models, seller payouts, click-and-collect and store inventory.
The basket splits into one customer order and several fulfilment orders per seller, the single payment is apportioned into a seller ledger that must survive a refund arriving after the payout, and the collect line is a promise made against a store count far less accurate than a warehouse's.