Activation Code Licensing System Design (Part 1): Foundations & Architecture

3 min read

Learn the foundations of activation code licensing, how it compares to subscriptions, and see the core architecture of a flexible, cross-platform licensing system.

Contents

• Introduction
  • Subscription or Entitlement Licensing
  • Activation Code Licensing
• Purpose of the Series
• System Overview
• Relationships
• Entity Diagram
• Design Justification

Introduction

Applications require licensing to enforce business models and to provide users with predictable ways to install and run software across devices. Two common approaches are subscription licensing and activation code licensing.

Subscription or Entitlement Licensing

In this model, access is tied to a user account.

• The application checks whether the user is logged in and whether their subscription is active.
• The backend may also return a list of entitlements (features, products, or seat counts the user is allowed to use).
• The client enforces those entitlements locally.

This approach works well when applications are always online and users accept authentication as part of usage. It also tightly couples licensing with connectivity.

Activation Code Licensing

This approach separates authentication from licensing.

• A code acts as a ticket, allowing a specific device to activate and run the application.
• Once activated, the application can continue working offline until the license expires.
• Expiry dates and maximum device counts are enforced, but constant connectivity is not required.

Purpose of the Series

This series explains how to design an activation code licensing system that is:

• Flexible across devices and platforms.
• Practical to enforce in backend, portal, and client applications without over-engineering.

Part 1 introduces the overall architecture and relationships. Later parts will cover constraints and code generation, activation flows, revalidation policies, security considerations, and database design.

System Overview

The activation system contains three main components:

1. Backend

   • Issues and enforces activation code constraints.
   • Generates codes, marks them as used, and creates activated devices.
   • Signs activation payloads with the private key.

2. Frontend Portal

   • Web interface for users to manage plans and activation codes.
   • Displays constraints such as free trial, paid subscription, or enterprise plan.
   • Shows how many codes have been generated and their usage status.
   • Allows users to generate or delete codes within plan limits.

3. Client Applications

   • Request activation with a code.
   • Store the returned payload (device_identifier, signature, expire_at).
   • Revalidate locally by verifying the signature with the public key and checking expiry.
   • Optionally revalidate online by checking with the backend.

Relationships

The entities in the system follow this hierarchy:

• Constraints define license plans (expiry date, maximum number of codes).
• Codes are generated from constraints (tickets, one-time use).
• Devices are created from codes (actual activations).

Entity Diagram

Design Justification

• The schema is simple and easy to understand.
• Integrity is enforced at the application level rather than through database foreign keys.
• Expiration-driven lifetimes ensure that expired constraints, codes, and devices naturally fall out of use.