System Model: Infrastructure Layer

1. Detail
2. See also

This page is part of the System Model. Infrastructure owns the transport and testing contracts. Everything above this layer speaks ores.nats; this layer provides the client, the service runner, the event bus, and the test fixture that wires them together. See Entity lifecycle for how ores.nats entities flow across request/reply pairs.

1. Detail

1.1. ores.nats

ores.nats messaging backbone — client connection management, subject naming conventions, queue groups, and JetStream configuration and lifecycle. The primary inter-service transport used by every domain and application component. See NATS for the technology overview.

Sub-component	Role	Dependencies
ores.nats	ores.nats client, subject conventions, JetStream	ores.platform

1.2. ores.service

Shared ores.nats domain service runner — the domain_service_runner template that gives every service a standard request/reply lifecycle: connect, subscribe, handle, reply, reconnect on failure.

Sub-component	Role	Dependencies
ores.service	ores.nats service runner template	ores.nats

1.3. ores.testing

Catch2 integration that isolates every test run into its own PostgreSQL tenant inside the shared database. Each run provisions the tenant, wires up a per-test logger and a database watchdog, and terminates the tenant at the end — making tests safe to run in parallel without seeing each other's rows.

Sub-component	Role	Dependencies
ores.testing	Per-test tenant isolation for Catch2	ores.database, ores.logging, ores.nats, ores.platform, ores.utility, ores.marketdata.api, ores.ore.core, ores.telemetry.core, ores.telemetry.database

1.4. ores.eventing

In-process publish/subscribe event bus with PostgreSQL-backed delivery and optional ores.nats integration. Decouples components within the same process from the ores.nats transport layer.

Sub-component	Role	Dependencies
ores.eventing	In-process event bus with PostgreSQL backing	ores.nats, ores.database

1.5. ores.telemetry

Observability — structured logs, service heartbeats, and NATS server and stream samples, gathered over the telemetry.v1.> subject namespace, stored in its own tables, and answered back to whoever queries. Its core part is the logging and tracing library every component links against.

Sub-component	Role	Dependencies
ores.telemetry.core	Logging, tracing and the messaging types every component links	ores.platform, ores.utility
ores.telemetry.database	PostgreSQL persistence for the four stored shapes	ores.database, ores.telemetry.core
ores.telemetry.service	ores.nats entrypoint for the six `telemetry.v1.>` subjects	ores.telemetry.core, ores.telemetry.database, ores.service, ores.nats

1.6. ores.storage

The client half of ORE Studio's object storage. It moves files between a local disk and an S3-shaped HTTP API that keeps objects under a bucket and a key: it owns the /api/v1/storage/{bucket}/{key} path shape, a synchronous Beast HTTP GET and PUT that stream file bodies rather than buffering them, a libarchive tar.gz pack and extract, and the atomic and composite transfer helpers the domain components call. It holds no bucket names of its own, so each caller names its bucket — ores.compute its package bucket, ores.ore its import and report buckets.

Sub-component	Role	Dependencies
ores.storage	Object storage client: bucket keys, HTTP file transfer, tar.gz archives	ores.utility, ores.platform

2. See also

System Model — the index page with the four-layer architecture overview.
System Model: Foundation Layer — the layer below.
System Model: Domain Layer — the layer above.
NATS — technology overview for the messaging backbone.
Entity lifecycle — how entities flow across ores.nats request/reply pairs.