Docs
[PLATFORM]

Core Concepts

To effectively build on PLTFRMS, it’s important to understand the core concepts that define how the platform is structured and how its components interact.

These concepts form the foundation of everything within PLTFRMS β€” from authentication and access control to product architecture and system design.


Organisations

An organisation acts as a namespace within PLTFRMS.

All resources β€” products, configurations, data, and services β€” are scoped to an organisation. This ensures clear separation between different environments, clients, or business units.

Organisations can also contain sub-organisations, allowing you to structure your setup hierarchically. This is particularly useful for:

  • Resellers managing multiple clients
  • Separating environments (e.g. production, staging)
  • Administrative or internal segmentation

Accounts

A PLTFRMS account represents an individual user.

Accounts do not own resources directly. Instead, they are granted access to one or more organisations.

Access is controlled through:

  • Roles β€” define what actions an account can perform
  • Groups β€” allow scalable permission management across multiple accounts

This model enables flexible and secure collaboration across teams and organisations.


Products

PLTFRMS is built as a multi-product platform.

Each product is a standalone component designed to solve a specific problem (e.g. IAM, payments, DNS, communication), while still integrating seamlessly with the rest of the platform.

All products share:

  • A unified access model (via organisations and accounts)
  • A consistent API structure
  • A shared infrastructure and event system

This allows you to combine products without dealing with fragmentation or inconsistent behavior.


Manager Services

Each product is driven by a dedicated manager service.

A manager service acts as the source of truth for that product’s state. It is responsible for:

  • Handling incoming requests
  • Validating and updating state
  • Emitting events when changes occur

This ensures that each product remains internally consistent and independently scalable.


Event-Driven Architecture

PLTFRMS is built around an event-driven architecture.

When a manager service processes a change, it emits an event into the internal event system. Other services can subscribe to these events and react accordingly.

Events can be:

  • Processed locally to update internal state
  • Used to trigger workflows or side effects
  • Transformed or enriched for further processing
  • Republished to other event streams

This approach decouples services, allowing them to evolve and scale independently while remaining part of a cohesive system.


Network & Infrastructure

PLTFRMS runs on infrastructure that is fully owned and operated in-house.

The platform is distributed across multiple datacenters, connected through a private backbone. Traffic is routed using BGP, with services exposed via:

  • /32 (IPv4) and /128 (IPv6) announcements

This enables:

  • High availability through multi-location deployments
  • Efficient traffic routing based on network conditions
  • Automatic failover between datacenters

Connectivity is established through a combination of:

  • Internet Exchanges (IXPs)
  • Private Network Interconnects (PNIs)
  • Upstream transit providers

Why it matters

These core concepts are what make PLTFRMS:

  • Scalable β€” each component can grow independently
  • Flexible β€” supports complex organisational structures
  • Reliable β€” built on resilient infrastructure and routing
  • Consistent β€” unified model across all products

Understanding these building blocks will help you design, integrate, and scale your own systems on top of PLTFRMS effectively.