01 System

System

An automated, multi-user, multilingual, event-driven information system built on PostgreSQL (hereafter referred to as the System) serves as the foundation for building modern, fault-tolerant, and scalable solutions.

The System consists of two key components: the Platform and the Configuration.

• Platform -- the universal core: a base set of tables and functions independent of any specific project's business logic, forming the Architecture of the System. It is a stable framework upon which functionality can be rapidly built.
• Configuration -- the application layer: a set of tables and functions implementing the business logic of a specific project. Each solution has its own configuration, precisely tailored to the customer's requirements.

Two-Layer Architecture

sql/
  platform/        <-- Framework (reusable core). Do not modify.
  configuration/   <-- Application-specific code. Edit here.

The execution order is always platform first, then configuration:

install  -->  platform/create  -->  configuration/create
update   -->  platform/update  -->  configuration/update
patch    -->  platform/patch   -->  platform/update  -->  configuration/patch  -->  configuration/update

Three API Layers

The System is entirely implemented in PL/pgSQL and represents a self-contained solution deeply integrated into PostgreSQL, with three levels of API:

1. Internal API in the kernel schema -- for low-level operations with the core;
2. External API in the api schema -- for secure application-level access;
3. REST API in the rest schema -- for integration with web services and external systems (invoked via api.run()).

This allows a unified PostgreSQL technology stack to serve as a complete backend: from the data core to REST interfaces.

Platform Module Loading Order

The platform consists of 25 modules loaded in strict dependency order:

#	Module	Purpose
1	kernel	Foundation: schemas, types, users, utilities, JWT
2	oauth2	OAuth 2.0 authentication
3	locale	Internationalization (i18n)
4	admin	Users, groups, areas, scopes
5	http	HTTP request/response types
6	resource	Static resource management
7	exception	Error handling framework
8	registry	Key-value registry (configuration storage)
9	log	Event logging
10	api	API dispatcher (api.run())
11	replication	Data replication support
12	daemon	Daemon/background process functions
13	session	Session management
14	current	Current session context (user, scope, locale)
15	workflow	State machine engine (entities, classes, states, methods, events)
16	kladr	Russian address classifier (KLADR)
17	file	File storage
18	entity	Complete entity system (object, reference, document, message, job)
19	notice	Notices
20	comment	Comments
21	notification	Push/email notifications
22	verification	Verification codes (email, phone)
23	observer	Observer pattern for event propagation
24	report	Report definition and generation framework
25	reports	Pre-built report definitions

Server Application

To interact with the System's API, a specialized Server Application is used, built on the Apostol framework and designed around the System's architecture.

Each project is assembled as a unique server solution from a set of ready-made modules:

• Web Server (HTTP)
• WebSocket API (WebSocket)
• Auth Server (OAuth 2.0)
• App Server (REST API)
• Message Server (SMTP/FCM/API)
• File Server
• Postgres File (PGFile)
• Postgres Fetch (PGFetch)
• Stream Server (UDP)

When needed, the solution is extended with custom modules and microservices, enabling the implementation of both standard scenarios and complex high-load systems.

The Server Application is compiled from source code as a Linux system service, ensuring predictability, manageability, and easy integration into existing infrastructure.

A finished project based on the System can be deployed in containers and managed by modern orchestration systems -- Docker Compose or Kubernetes -- simplifying scaling, updating, and maintenance in any environment: from test stands to production clusters.