Core Features

Version Management

All meaningful changes to both content and configuration are versioned, regardless of where or how that data is used in the system.

This includes, but is not limited to:

• Creating or updating content
• Publishing or unpublishing content
• Editing configuration values
• Activating or deactivating rules
• Changing market-specific settings
• Updating shared or global configuration used by multiple applications

Each change results in a new immutable version, stored as events in streams.

Versions can always be:

• audited
• compared
• replayed
• reverted

This ensures consistency, traceability, and safety across the entire platform.

---

Audit & Change Logs

Orbital provides system-wide change logs through its standardized Message structure. Anytime a change is made to a Message, a change log is generated by analysing the previous version to the new, after which is appended to the new Message. When the Messages is stored in the stream, a consumer will read it, and push it to an index or searchable database:

flowchart TD

  %% Orbs
  O1["Ørb 1"]
  O2["Ørb 2"]
  O3["Ørb 3"]
  O4["Ørb 4"]

  %% Streams
  S1[(Stream)]
  S2[(Stream)]
  S3[(Stream)]
  S4[(Stream)]

  %% Consumer and DB
  C["Consumer"]
  DB[(Searchable DB<br/>or Index)]

  %% Orb to Stream
  O1 --> S1
  O2 --> S2
  O3 --> S3
  O4 --> S4

  %% Streams to Consumer
  S1 --> C
  S2 --> C
  S3 --> C
  S4 --> C

  %% Consumer to DB
  C --> DB

This ensures system-wide:

• regulatory compliance
• traceability
• accountability

without adding manual overhead.

---

Scheduled Publish & Unpublish

Orbital supports system-wide, time-based activation and deactivation of data using validFrom / validTo semantics.

flowchart TD

  %% Orbital Core
  subgraph Core["Orbital Core"]
    direction TB

    O1["Ørb 1"] --> S1[(Stream)]
    O2["Ørb 2"] --> S2[(Stream)]
    O3["Ørb 3"] --> S3[(Stream)]
    O4["Ørb 4"] --> S4[(Stream)]
  end

  %% Scheduling Layer
  subgraph Sched["Asynchronous Scheduling Layer"]
    direction TB

    VC["validFrom / validTo<br/>Consumer"]
    ADD["Register scheduled action<br/>(publish / unpublish)"]
    MQ[(Monitored Queue)]
    RUN["Execute scheduled action<br/>(publish / unpublish)"]
  end

  %% Streams feed scheduler
  S1 --> VC
  S2 --> VC
  S3 --> VC
  S4 --> VC

  %% Scheduling flow
  VC --> ADD --> MQ
  MQ -. "time reached" .-> RUN

  %% Write-back (conceptual)
  RUN --> WB["Publish / unpublish<br/>back to originating stream"]

  %% Styling
  style Sched stroke-dasharray: 6 4

This includes, but is not limited to:

• Content pages
• Rules activation and deactivation
• Game launches
• Capsule enable/disable
• Service and platform configurations

Because scheduling is applied at the data level, any managed Message in the system can potentially participate in scheduled lifecycle changes.

A monitored queue ensures that all scheduled actions are executed reliably, deterministically, and consistently across the entire system.

---