E-Learning & Course Delivery Platform

Payment providers guarantee at-least-once delivery, not exactly-once. The same "payment succeeded" event can arrive twice, or arrive while the first copy is still being processed — and fulfilling on receipt turns one card charge into two enrolments, two orders and two payment records.

I split receiving the event from acting on it. Every delivery is written to a receipt table first, keyed on the provider's own event id, so concurrent inserts are absorbed by a unique index rather than by application-level checking. The receipt is then re-read inside a transaction with a row lock, so a second delivery waits instead of racing, and a processed marker short-circuits anything already handled.

The part that matters is that the marker and every fulfilment write commit or roll back together. There is no window where a learner is enrolled but the event is not marked done, or the reverse. Fulfilment reads the originally verified payload, so a receipt written but never finished stays replayable rather than disappearing, and the transaction retries on deadlock.

Two clicks on "claim my certificate" must not produce two certificates, and two certificates must never share a number.

Issuing runs in a transaction that opens by locking the learner's certificate entitlement — the thing that is genuinely one-to-one with a certificate — which serialises simultaneous claims. If a certificate already exists for that entitlement, the loser of the race is handed the winner's certificate rather than an error.

The number is derived from the certificate row's own primary key. The alternative, reading the current maximum and adding one, is the bug: two claims committing at the same moment would both read the same answer before either inserted. Deriving it from the key means uniqueness comes from the database rather than from application-level care. The verification token is forty-eight random characters rather than a sequence, so certificates cannot be enumerated.

A certificate carries a name, a course title, a level and a provider. All of those stay editable afterwards. If the certificate renders live data, correcting a course title next year silently rewrites evidence issued this year.

So what a certificate displays is frozen into its own record at the moment of issue, and read back from there forever.

The same discipline applies one level down, to quiz attempts — with one extra decision I would defend hardest. The frozen attempt records what was asked, in order, what was chosen and how each answer was marked, and it is explicitly excluded from scoring. It is a record of what happened, not a source of truth for the live quiz. A snapshot that could have been used for marking, and deliberately is not.

Prices lived in two columns for historical reasons, a sale price of zero has to mean "no sale" rather than "free", and a browser would happily choose its own amount.

A single pricing service resolves the payable amount, and the same service produces both the storefront display price and the figure sent to the payment provider, so the two cannot diverge. Money is handled in minor units throughout and converted from the fixed-point string rather than through a float. A non-null minor-unit value wins including zero, so a null sale price means no sale rather than falling back to a stale decimal mirror.

Eligibility is re-read from persistence at the moment of purchase: the policy refetches the course and checks the raw stored status, because an already-loaded model or a pending order is not permission to buy. The admin form states the contract to whoever types into it — four thousand nine hundred and ninety-nine means £49.99, and that is what will be charged.

Some courses are regulated qualifications awarded by an external organisation. For those, issuing a platform certificate is not a feature — it is a compliance error.

The course editor asks the defining question first: what kind of thing are you creating? That choice rewrites the rest of the form, and for a regulated qualification the certificate policy is switched off and cannot be re-enabled, stated in plain language in the interface rather than hidden in a disabled control.

The issuing action then refuses independently, for a reason worth stating: an entitlement may predate the course being marked regulated. One enforcement point would have been a bug waiting for somebody to reclassify a course.

Originally one order meant one payment session, enforced by unique indexes. Basket checkout broke that: one session and one payment intent now cover several orders, so those columns cannot stay unique.

Dropping a unique index is exactly how replay protection gets lost by accident. So the migration that did it spends a paragraph explaining where the protection actually lives — a delivered event is recorded once by its provider event id and skipped if already processed, each order refuses fulfilment a second time once it is paid or refunded, and fulfilment still refuses to act when the session presented does not match the one the order was created with.

The schema change is a written argument, not just a schema change. Anyone later asking "why is this not unique any more?" gets the answer from the code.