TitanTech Electronics Store

Context

Built to a written PRD rather than a tutorial spec. One vendor, one currency, one country's delivery model — so the hard problems here are correctness problems, not scale problems.

Challenge

Two customers buying the last item in the same second. A store that sells stock it does not have is not a store, and the browser is the last place I would trust to work out what anything costs.

Non-negotiables

• Stock can never go negative, under any concurrency
• Totals are the server's, never the client's
• Payment confirmation has to survive a replayed or forged browser redirect

Calls I made

1. 01

   One doorway for every stock movement

   Order confirmation, cancellation, admin adjustment, and restock all go through the same function. The append-only inventory log is only trustworthy if nothing writes the stock column behind its back, so summing a variant's deltas has to reconcile to its current stock. That reconciliation is the integrity check the whole design exists to support.

2. 02

   Money is recomputed, never received

   Totals are calculated server-side at cart view, again at checkout quote, and again at placement. The browser never submits a price. The payment redirect is treated as UI only — the IPN handler re-validates against SSLCommerz, checks the paid amount against the stored total, and is idempotent so a replayed callback changes nothing.

3. 03

   The admin is gated server-side

   The admin is a route group in the shopper's build, code-split out of their bundle. Hiding a button in React is never the access-control mechanism — permission classes on the API are.

4. 04

   Compatibility as a first-class result

   The PC builder checks socket, memory generation, form factor, and power draw as parts are added, and keeps error, warning, and info findings distinct. A part that will not physically fit is a different thing from one that merely draws a lot of power, and collapsing the two would make the feature useless.

The decision, in code

Locking in a deterministic order

def lock_variants(variant_ids):
    """
    Lock the given variant rows for the rest of the transaction.

    The oversell guard lives here: SELECT ... FOR UPDATE in primary-key order.
    Deterministic ordering is not decoration -- two concurrent checkouts holding
    overlapping baskets in different orders deadlock, and MySQL resolves that by
    killing one transaction at random.
    """
    ids = sorted({int(value) for value in variant_ids})   # <- the whole trick
    if not ids:
        return OrderedDict()
    rows = (
        ProductVariant.objects.select_for_update()
        .filter(pk__in=ids)
        .order_by("pk")
    )
    return OrderedDict((row.pk, row) for row in rows)


def record_movement(*, variant, delta, reason, actor=None, order=None, note=""):
    """
    Apply one stock delta and write its audit row. Never do one without the other.

    Assumes the caller holds the row lock. A negative result is refused here as a
    last line of defence, before the database CHECK (stock >= 0) would refuse it
    far less legibly.
    """
    new_stock = variant.stock + delta
    if new_stock < 0:
        raise DomainError(..., code="INSUFFICIENT_STOCK")

    ProductVariant.objects.filter(pk=variant.pk).update(stock=F("stock") + delta)
    return InventoryLog.objects.create(...)

The `sorted()` is the load-bearing line. `SELECT ... FOR UPDATE` alone stops the oversell, but two baskets that share items and lock them in opposite orders deadlock — and the database breaks the tie by killing someone's checkout. Sorting by primary key gives every transaction the same acquisition order, so they queue instead of colliding. The `CHECK (stock >= 0)` underneath is the backstop: if a path ever skips this function, the write fails rather than silently overselling.

Trade-offs accepted

• Locking variant rows for the duration of checkout serialises customers who want the same item. That is the correct trade at one vendor's volume, and it is also the first thing that would need revisiting under real contention — the lock is held across work that does not strictly need it.
• Product imagery is pulled from openly-licensed Wikipedia and Wikimedia sources with licence and author stored per image. It keeps the catalogue honest and attributable, but it means the photography is generic rather than the vendor's own.