Loading...
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.
23 published across 9 topics.
Product modelling, variants, attributes, taxonomy and enrichment.
Measure completeness per category against the filters shoppers use, not across the whole catalogue. Then fix it at the source with required attributes per category and supplier gates, infer only with recorded provenance, and suppress a filter whose coverage is too low to be honest.
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.
Separate the three cases first, because they need different treatment. Availability is a per-request fact rather than an index field, so filter at query time from a fast availability source and reserve suppression for what is genuinely delisted.
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.
Sort each dependency by what the loss looks like. Price and payment authorisation must fail closed because the loss is unrecoverable; personalisation degrades silently. Tax and fraud sit between, and the answer is a written policy with a bounded exposure, not a timeout value.
Reservations, oversell versus lost sales, multi-location availability and physical drift.
The oversell sits in accepted orders, not in on-hand stock. The checkout gate read a cached availability projection while orders arrived faster than it refreshed, so the promise ledger went negative and the stock ledger never had to. You fix the gate, not the cache.
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.
There is no single point of no return - each downstream hand-off has its own. Model the change as a request that can be refused, priced and re-screened rather than an edit to the order, because a new address can move the shipping cost, the tax base and the fraud risk.
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.
Nothing in the pricing engine was broken, so the control has to sit on the change itself: bounds relative to the previous price and the cost, a rate limit on bulk movement, and a kill switch. Then pause dispatch before anyone debates whether to honour the orders.
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.
Write the order before you call the payment provider and key both with the same idempotency token, so a timeout leaves a record you can resolve. Then reconcile the provider's ledger against your orders daily in both directions, because a lost outcome is silent by default. Use this payment orchestration answer to show the decision, trade-off, and evidence rather than a memorised definition.
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.
Almost always the unit was restocked as sellable on receipt, before anyone graded it. Receipt and grading are different events with different owners, and the returned unit must sit in a non-sellable location until a disposition decision has been made and recorded. Use this returns grading answer to show the decision, trade-off, and evidence rather than a memorised definition.
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. Use this returns answer to show the decision, trade-off, and evidence rather than a memorised definition.
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 store can only accept it if the platform decides at the counter, funds the refund itself and recovers it from the seller's payout. That leaves you holding another company's goods on your floor and an unsecured balance if the seller has nothing left to offset against.
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.