A provider-agnostic system for assigning digital license keys to orders across multiple regions and certification providers.
This document describes a system that assigns digital license keys to customer orders across several storefronts, financing partners, and regions. It supports multiple certification providers without encoding any of them in its schema or code — provider behaviour is expressed as data and configuration. The system guarantees exactly-once delivery, atomic seat allocation, and region isolation, and records an audit trail for every assigned key.
An order originates in one of five sources: three regional storefronts and two financing channels. Orders are received by an orchestration layer, which sequences calls to a stateless key engine. The engine resolves the ordered product to a set of entitlements, allocates keys from inventory, and confirms the result before delivery.
Keys are stored in a database separate from the business data and are reached only through the engine. The order channel never accesses them directly. A control plane — an operator-facing admin surface and a sync layer — configures the catalogue and imports inventory, but plays no part in the live order path.
The system serves four certification providers, each selling different products under different codes. Keys exist in three shapes — combined, content-only, and exam-only — and delivery timing differs by channel: immediate for full payment, milestone-staged for installment plans. Keys are partner intellectual property and are imported separately from the product catalogue.
The obvious approach models this diversity directly in the schema. That couples storage to business rules, and every commercial change becomes a migration or a deployment. The table below sets the constraints against the failure modes of a direct model.
The schema therefore models none of this. Providers are data, business rules are configuration, and keys are addressed by value, not reference.
Three decisions follow from that principle. Together they let the commercial surface — providers, regions, bundles — change without touching the engine or the schema.
A key is identified by the natural tuple (region, provider, product_code) and holds no foreign key to a product row. The catalogue is rebuilt from the storefront on a regular cycle; because nothing references a product, a rebuild cannot orphan a key. The two need only agree on a value, so adding a provider or product is an insert with no migration.
Each product declares the access it grants as an entitlement string. There is no separate product-to-key mapping table — the entitlement is the source of truth, parsed at order time into the keys to assign, and the same entitlement drives the live availability count shown on the storefront. If a product has no entitlement, or the keys it points to are exhausted, availability resolves to zero and the product cannot be ordered. The chain fails closed.
License keys are partner intellectual property and are held in a database project separate from the business data. The business database exposes them through a foreign-data-wrapper view, so the key engine queries a single table name and does not distinguish local from remote storage. Isolation is structural rather than a matter of discipline — order and product data never share a database with the keys.
The path for a fully-paid order runs through five steps. Every step is stateless and idempotent, so the orchestration layer may retry any call without risk of issuing a key twice.
Installment plans reuse the same engine, releasing access in step with payments rather than all at once: content keys at the first milestone, the exam key on final payment. Intermediate payments deliver nothing.
The system handles money and a finite, valuable inventory. The following properties hold regardless of retries, concurrency, or duplicate webhooks.
The architecture turns several formerly manual or risky operations into routine ones.
The system was designed to decouple revenue growth from operational overhead — built for a $1M → $4.5M ARR expansion across multiple regions and markets. New providers and regions come online through configuration. Custom product bundles require no engineering involvement and are accessible through a mobile interface for the sales team. 20–30 hours of weekly manual operations collapse into a single monitoring surface requiring only periodic inventory imports. The pattern applies to any digital product business with the same shape: multiple suppliers across multiple regions. Commercial velocity, decoupled from engineering capacity.