---
title: 'Multi-site federation'
section: 'Operations'
weight: 2
badge: 'new'
description: 'A Data Platform module for organizations with multiple independent installations: a single registry of sites, monitoring of site availability and data intake, summary metrics across the whole network, and access to any site without signing in again.'
related:
  - operations
  - architecture/scalability
  - security
---

import Image from '@/components/docs/Image.astro';

**Federation** is a Data Platform module for organizations with multiple independent installations. It combines sites — separate installations of the platform in regions, branches, and subsidiaries — into a single network. One screen shows the state of that network: which sites are running normally, whether data is arriving from metering devices, and how many metering units are being monitored in total.

The module is designed for federations of up to 100 sites, each with anywhere from hundreds of thousands to several million metering units.

<Image
  src="/images/federation/01-summary-light.webp"
  alt="Federation summary: site status tiles, totals across all sites with trend sparklines, and an overall metrics trend chart"
  caption="Summary of a 10-site federation: 451,539 metering units, 437,391 customers, 473,533 metering devices"
  width={1440}
  height={900}
/>

## Capabilities

- A single registry of sites, grouped by country, region, or owner
- Monitoring of each site's availability and of data intake from its devices
- Summary metrics across the whole network: metering units, customers, devices, communication sessions, monitoring events, and parse errors
- Metric trends over 30 days — for the federation, for a group, and for an individual site
- A map of sites with color-coded status
- One-click access to any site without re-entering a password
- Secure site onboarding and automatic access key rotation
- A log of requests made to each site, for troubleshooting

## Key principles

1. **Data stays at the site.** The federation console receives only aggregate counters. Information about individual metering units, devices, and measurements does not leave the site.
2. **The site grants access.** The console connects to a site using a key issued by that site's administrator, and only the site administrator can revoke it.
3. **Scale does not affect speed.** Metrics are collected on a schedule and stored in the console, so the summary opens instantly regardless of the number of sites.
4. **Responding is not the same as working properly.** If a site responds but receives no data from its devices, the console flags it separately.
5. **Secrets stay on the server.** The access key is stored encrypted and is not sent to the browser; signing in to a site uses a one-time ticket.

## Main screens

### Summary

This is the operator's main screen. It brings together status tiles, totals with trends, data quality, site groups, and a table that gives each site its own row with a 30-day collection history.

<Image
  src="/images/federation/02-nodes-table-light.webp"
  alt="Sites table: for each site, its state, platform version, 30-day collection history, collection lag, response time, number of consecutive failures, and a button that opens the site"
  caption="Sites table: state, version, 30-day collection history, response time. The Bukhara site is responding, but its data intake has stopped; the Nukus site is running an outdated version"
  width={1136}
  height={833}
/>

### Map

The map shows sites color-coded by status: green — running normally; orange — responding, but no data is arriving; red — not responding or refusing the key.

<Image
  src="/images/federation/03-nodes-map-light.webp"
  alt="Federation map with colored site markers and a status legend"
  caption="Federation map: sites in Uzbekistan, Kazakhstan, and Kyrgyzstan"
  width={1136}
  height={671}
/>

### Registry and site card

The registry is the complete list of sites, filterable by group and status. The site card shows the site's version, supported features, access key, latest metrics, trends over the past month, and a log of requests that ended abnormally.

### Opening a site

The **Open the node** button opens a site without prompting for a username and password. The operator works under a service account with view permissions and can return to the console with the **← Federation** button in the site's header.

<Image
  src="/images/federation/04-open-node-light.webp"
  alt="Site dashboard opened from the federation console: cards for objects, customers, metering complexes, and shutoff devices, plus object statuses; the header contains the button that returns to the console"
  caption="The Tashkent site opened from the console: 86 thousand metering units, and the return-to-console button in the upper left"
  width={1440}
  height={900}
/>

### Fault monitoring

The console distinguishes between common faults and suggests where to look for the cause: the site is unreachable over the network, it refuses the key, data intake from its devices has stopped, or its platform version is outdated.

<Image
  src="/images/federation/05-incidents-light.webp"
  alt="Sites table with three simultaneous faults: one site is unreachable, another refuses the key, and data intake has stopped at a third"
  caption="Three faults at once: Almaty is unreachable, Karaganda refuses the key, and data intake has stopped at Bukhara"
  width={1136}
  height={834}
/>

## Onboarding a site

| Step | Performed by        | Action                                                                        |
| ---- | ------------------- | ----------------------------------------------------------------------------- |
| 1    | Site administrator  | Issues a key for the federation in the **Access tokens** section              |
| 2    | Federation operator | Registers the site in the console: code, address, group, coordinates, key     |
| 3    | Federation operator | Clicks **Probe now** and confirms that the site is in the **Answering** state |

The first metrics appear within 15 minutes; trends become available the next day.