# Deployment topologies

> How a NYXDB deployment is laid out — node processes, tablets and replicas, and the checks to run before going live.

## A node

A NYXDB node is one process. It serves the HTTP and WebSocket gateway, SQL,
the tablets that hold table data, PSI, and every derived consumer: indexes,
transformations, materialized views and streams. A write is acknowledged once
the node's write-ahead log holds it.

## Tables across nodes

A table is split into shards by its `SHARD BY` key. Each shard is a tablet
with its own write-ahead log domain. Tablets are replicated across nodes, and
a replica takes over when a node is lost; tablets move, split and merge as the
data grows.

| Layer | What it does |
| --- | --- |
| Gateway | Authenticates sessions and routes each statement. |
| Tablets | Own the rows of one shard, their history and their indexes. |
| PSI | Publishes every committed change once to every subscriber. |
| Derived consumers | Keep transformations, views and streams current. |

## Pre-deployment checks

- `GET /auth/issuers` lists the `password` and `api_key` issuers once the
  issuer key is configured.
- Read `system.settings` on a WebSocket session to confirm the effective node
  values of the registered settings and their origin.
- Confirm that a user without a role is denied a read (403) and that the same
  read succeeds after a role grants `relation_read`.
- For federation, confirm `system.sources` reports each source `ready`.

---

Source: https://nyxdb.io/docs/operations/supported-boundaries/