> For the complete documentation index, see [llms.txt](https://docs.rumi.systems/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rumi.systems/rumi-management/concepts/architecture.md).

# Architecture

Rumi Management has two architectural flows — one for command, control, and scripting, and one for telemetry. This page covers both in summary; the [Deployment Lifecycle](/rumi-management/concepts/deployment-lifecycle.md), [Deployment Model](/rumi-management/concepts/deployment-model.md), [Command and Control](/rumi-management/concepts/command-and-control.md), [Scripting](/rumi-management/concepts/scripting.md), and [Telemetry Model](/rumi-management/concepts/telemetry-model.md) pages cover each in depth.

## Command, Control, and Scripting

<figure><img src="/files/gwOPuYD4ZWC4K3fSB1ND" alt=""><figcaption></figcaption></figure>

Ad-hoc command-and-control (start, stop, thread dump, trace level changes, app-specific commands, …) and scripted deployments follow the same path:

**Rumi Admin → Rumi Agent (REST) → Embedded Controller → Target Container**

Inside each container, incoming commands are dispatched to:

* **Application logic** — app-specific commands (e.g., order cancel, cache refresh).
* **Rumi Engine** — engine commands (e.g., change trace level, stop).
* **JVM** — JVM commands (e.g., thread dump, kill).
* **Host** — host commands (e.g., clear memory cache).

Because both flows terminate at the Agent's REST API, any REST client — the Admin UI, a CI/CD pipeline, or a custom script — can issue commands or run deployment scripts.

## Telemetry

Rumi Management observes running containers through three kinds of signals:

* **Telemetry** — aggregated metrics from the container (JVM, host, engine, and application-specific counters, gauges, series, and records), carried in periodic heartbeats. Telemetry is forwarded through the Agent to a time-series database for dashboarding and alerting.
* **Lifecycle events** — as-they-occur notifications of container, service, and bus-connection state changes. Lifecycle events are consumed by the Controller to build and maintain the deployment model; they are not re-emitted as a separate event stream.
* **Alerts** — as-they-occur notifications of noteworthy conditions. Planned as an additional signal; not yet supported.

<figure><img src="/files/5JpZERgUdJ9S8omMkuUx" alt=""><figcaption><p>Telemetry flow from container to dashboards.</p></figcaption></figure>

Each Rumi container runs a telemetry collector that aggregates:

* **Application-specific metrics** — counters, gauges, series, and records from application logic.
* **Engine metrics** — queue depths, latencies, and internal statistics from the Rumi Engine.
* **JVM metrics** — heap, JIT, and runtime metrics.
* **Host metrics** — disk and CPU metrics.

The aggregated telemetry is emitted from the container in each heartbeat. Heartbeats travel to the Rumi Agent over a direct TCP session or a pub-sub bus, depending on the Agent's telemetry mode. The Agent writes the telemetry to a time-series database (InfluxDB), and Rumi Monitor visualizes the stored data through dashboards.