The Checkout and the Classroom Are Not the Same System

A lot of education businesses are also commerce businesses. Someone buys a course, a subscription, a bundle of test preparation, or a physical item alongside it, and then studies. We have built platforms of exactly this shape — including a biotechnology e-learning platform sitting alongside an e-commerce operation and a reference library.

It is natural to build this as one application. Same users, same catalogue, same login, same brand. And it is the wrong instinct, because the two halves have opposite tolerances, and the boundary between them is where the defects that actually cost money live.

Opposite tolerances

Commerce is a transactional system where money changes hands. It has to be exactly right, exactly once. A double charge is a refund, a support ticket and a chargeback. A payment recorded but not fulfilled is a customer who paid and got nothing. Every write in that path needs to be idempotent and auditable, and the correct response to uncertainty is to stop and reconcile.

Learning delivery is a read-heavy content system with soft consistency requirements. If a progress marker lands a second late, or a video position is a few seconds out, nobody is harmed. What learning delivery cannot tolerate is being slow or unavailable, because a learner in a study session hits it hundreds of times.

Build these with one set of assumptions and you get one of two bad outcomes. Apply transactional rigour throughout and every lesson view becomes an expensive consistency exercise, which is slow and costs more to run than the business supports. Apply content-system looseness throughout and the payment path acquires the defect class of a cache — which is how a platform ends up granting access it was not paid for, or charging for access it did not grant.

Entitlement is the seam, and it belongs to neither side

Between "they paid" and "they can study" sits a question that is easy to state and easy to get wrong: what exactly is this person allowed to access, right now?

The temptation is to answer it by looking at the order. Find the purchase, check what it contained, allow those things. It works until any of the following happens — and all of them happen:

A subscription lapses, so entitlement has an end date the order does not describe. A refund is issued, so a completed order must stop granting access. A bundle is repackaged, so the catalogue changed after the purchase and the order refers to things that have moved. An institution buys seats and assigns them, so the payer and the learner are different people. A promotional period grants temporary access with no order at all. Someone is given access by support, for a good reason, with no payment involved.

Each of these is trivially handled if entitlement is its own concept — a record that says this identity may access this thing between these dates, for this reason — and each becomes a special case grafted onto order-reading logic if it is not. The version of this code that inspects orders accretes conditionals until nobody can say with confidence who can see what, and the failure is invisible from the outside until a learner is either wrongly blocked or wrongly admitted.

Making entitlement explicit also gives you the answer to "why does this person have access", which is a question support asks daily and finance asks at the end of every quarter.

What breaks under load, and when

The two halves fail at different times, which is a strong argument for not letting them share fate.

Commerce load is spiky and predictable: an enrolment window, a launch, a discount period. Learning load is heavier in aggregate and follows a study rhythm — evenings, weekends, the weeks before an examination.

A platform serving a professional or academic audience gets an unpleasant combination of these. The enrolment spike and the study peak can land in the same week, and if the video delivery path and the payment path contend for the same database connections, the checkout fails at the moment the business is trying to take money. That is the outage that matters, and it is caused entirely by co-location.

They also have opposite scaling shapes. Content delivery scales with caching and a CDN and barely touches the origin. Payment cannot be cached at all. Treating them as one system means sizing for the sum of two workloads that have nothing in common.

Deployment risk

The last argument is organisational, and in practice the most persuasive one.

Content changes constantly: new courses, corrections, reordered modules, updated reference material. It should be changeable by people who are not engineers, and deployable without ceremony.

The payment path should change rarely, under review, with a tested rollback. It touches money and it is in scope for whatever compliance regime applies.

One codebase means one release cadence, and the cadence will be set by whichever side is more cautious — or, worse, by whichever side is louder. If content wins, the payment path is being redeployed several times a week by people who were editing a course description. If payment wins, publishing a correction to a lesson requires a release process designed for financial software, and the content team stops using the system as intended.

The shape that holds

Keep them separate and keep the seam narrow. Commerce owns orders, payments, refunds and invoices, and emits a single fact when something is bought. Entitlement owns the answer to who may access what and why, derived from that fact and from everything else that grants access. Delivery owns content, progress and the learning experience, and asks entitlement rather than inspecting orders.

That is three components with one clean question between them, rather than one application with the question implied in a dozen places. The refactor is straightforward at the start and expensive later — which, as usual, is why it is worth doing at the start.

---

iLeaf builds e-learning and commerce platforms, with fifteen years of backend and architecture delivery behind them. See the work or tell us about the project.