Skip to content
Orbital Orbital Docs

Introduction

Orbital is a composable application platform designed for systems that operate across multiple markets under complex regulatory constraints, while remaining lightweight and cost-effective for much simpler use cases.

It addresses a set of recurring, compounding challenges commonly found in such environments:

  • Diverging legislation and compliance requirements across countries and subdivisions
  • High operational cost and friction when launching, adapting, or maintaining markets
  • None or limited support for geographical subdivisions within countries
  • Manual, slow, and error-prone handling of market-specific content and configuration
  • Market-dependent rules for content, payments, games, and other domain logic
  • Complex and fragile infrastructures, often built around tightly coupled databases and services

At their core, these challenges stem from the same underlying issues: inconsistent data models, duplicated or hardcoded logic, and market-specific exceptions scattered across codebases and systems.

Design Principles

Section titled “Design Principles”

Static Core, Asynchronous Extensions

Section titled “Static Core, Asynchronous Extensions”

To reduce infrastructure complexity and operational fragility, Orbital is intentionally static at its core. All primary data is stored as immutable messages in NATS JetStream, and any need for traditional databases exists outside of Orbital’s core functionality.

In practice, the need for external databases is minimal. Most requirements can be satisfied using asynchronous consumers together with JetStream’s built-in capabilities, such as key–value stores and ordered streams.

Database-style access patterns—such as deep content search, complex aggregations, or advanced filtering—are implemented asynchronously using dedicated consumers that materialize message data into external systems. These materialized views are kept near real-time without introducing synchronous coupling.

By limiting external databases to cases where they are strictly necessary, Orbital avoids tightly coupled infrastructures and remains small, predictable, and highly stable, with very few moving parts.

Uniform Data Handling

Section titled “Uniform Data Handling”

To address duplicated logic and inconsistent data models, Orbital enforces a single guiding principle: all data is structured, versioned, localized, processed, and stored through the same underlying mechanisms, regardless of what that data represents.

This uniformity enables:

  • consistent and predictable system behavior
  • reusable tooling and infrastructure
  • inherited defaults instead of duplication
  • full auditability and traceability across the platform

Uniform Data Derivation

Section titled “Uniform Data Derivation”

To avoid parallel implementations and configuration drift, Orbital treats its standardized data structures as the authoritative source for both system behavior and external interfaces.

From this source, Orbital automatically derives:

  • API endpoints for modifying data through back-office interfaces
  • Back-office user interfaces for inspecting and manipulating that data
  • API endpoints for reading data in customer-facing applications (where needed)

This significantly reduces duplication and removes the need to manually create and maintain separate data models, APIs, and administrative tooling.

Core Concepts

Section titled “Core Concepts”

At a high level, Orbital is defined by six core concepts that together describe how data is structured, stored, and localized across the platform:

Ørbs

Section titled “Ørbs”

Ørbs are self-contained applications built on the Orbital architecture. Each Ørb has:

  • its own NATS JetStream for Message storage
  • dedicated, generated API endpoints
  • a dedicated, generated Back Office UI
  • no runtime dependencies on other Ørbs

Modules

Section titled “Modules”

Logical containers within an Ørb that define the type of Messages they may contain:

  • CONTENT – localizable and translatable content
  • CONFIG – localizable configuration that is not translatable
  • RULES – business rules with specialized evaluation
  • TRANSACTIONS – transactional or financial data with a linear lifecycle PLANNED
  • SETTINGS – declarative Messages that cannot be disabled or unpublished PLANNED

Schemas

Section titled “Schemas”

Definitions of data structure and validation rules, constrained by the type of their parent Module.

Entries

Section titled “Entries”

Concrete data instances that conform to the structure defined by a Schema.

Markets

Section titled “Markets”

Configurations representing geographical locations, ranging from multiple countries down to sub-regions within a single country.

Messages

Section titled “Messages”

A JetStream message that follows a mandatory, standardized structure with root-level metadata. With the exception of explicitly storing raw third-party data, all data in Orbital is represented as a Message, including Orbital’s own configurations and settings.

Ørb configurations, modules, schemas, content, and rules—whether client-side or server-side—are all Messages.

There are three categories of Messages in Orbital:

  • Managed – non-linear status lifecycles: SAVED, PUBLISHED,UNPUBLISHED and ARCHIVED.
  • Declarative – value updates only, without lifecycle state
  • Transactional – strictly linear lifecycles: INITIATED → PENDING → COMPLETED

Terminology and Naming

Section titled “Terminology and Naming”

Because Orb, Module, Message, Schema, and Entry are widely overloaded terms, Orbital assigns them precise, platform-specific meanings.

When referring to Orbital concepts, these terms are capitalized. When used outside the Orbital context, they should be explicitly qualified (for example, “database schema”) and written in lowercase.

  • Ørb — an Orbital application
  • Message — a JetStream message with standard Orbital metadata
  • Module — a data container within an Ørb
  • Schema — a data structure definition
  • Entry — a data instance conforming to a specific Schema

Conceptual Hierarchy

Section titled “Conceptual Hierarchy”

These concepts form a strict and consistent hierarchy throughout the platform:

  1. Ørbs – define Modules
  2. Modules – define allowed Message categories and constrain Schema types
  3. Schemas – validate Entries
  4. Entries – carry state

Consistency as a Core Principle

Section titled “Consistency as a Core Principle”

By relying on a small and consistent set of core capabilities, Orbital addresses the structural causes of duplicated logic and market-specific exceptions. Uniform mechanisms for defining, storing, and processing data keep the overall codebase compact and maintainable.

The result is a platform that is stable by design, adaptable over time, and able to grow in a controlled and predictable manner.