# Architecture

> A NYXDB node — the HTTP and WebSocket gateway, SQL, tablets with an owner, WAL domain and parts, PSI, and the derived consumers.

A NYXDB node is one process. Everything a client reaches — sessions, SQL,
storage and derived results — runs inside it, and nodes replicate tablets to one
another.

- clients — HTTP, WebSocket
  ↓
- gateway — HTTP routes, WebSocket sessions, authentication
  ↓
- SQL — parse, bind, plan, execute
  ↓ writes (↑ reads)
- tablets — one owner per tablet, a WAL domain, immutable parts
  ↓ every committed batch
- PSI — the committed-change feed
  ↓
- transformations · materialized views · indexes · streaming reads

## Gateway

The gateway accepts HTTP requests and WebSocket sessions. HTTP carries session
exchange, one-shot SQL and the bulk write routes. A WebSocket session on
`GET /client` multiplexes many requests, including streaming reads, by request
id. Every request runs under an authenticated session; see
[Authentication](/docs/concepts/authentication) and
[Protocol](/docs/drivers/protocol).

## SQL

One statement per request, at most 64 KiB. The engine parses, binds against the
catalog, plans and executes it. Credential statements and federation
statements are classified before the relational parser and never reach it.

## Tablets

A table is split into tablets by its `SHARD BY` clause; the shard count is fixed
when the table is created. Each tablet has one owner that serializes its
commits, identified by an owner epoch and a commit sequence. Records go to a
local, segmented, checksummed write-ahead log (WAL) with group commit, and a
write is acknowledged only after it is durable. Each runtime
has a set of WAL domains, and each tablet maps to one of them.
Committed data is kept in immutable parts. See [Storage](/docs/concepts/storage).

## PSI

Every committed tablet batch is published once on that tablet's committed feed.
Subscribers select changes by relation, component and key, keep their own
durable cursor and acknowledge only what they applied; the tablet never waits
for them. See [PSI](/docs/concepts/psi).

## Derived consumers

Transformations, materialized views, indexes and streaming reads are PSI
subscribers. A transformation writes into an ordinary table, so its output is
again published on PSI and can feed the next transformation. See
[Transformations](/docs/concepts/transformations) and
[Streaming reads](/docs/concepts/streaming-reads).

## Control plane and replication

A Raft quorum runs the control plane. Each tablet is replicated across nodes; when
a node is lost, a replica takes over. Tablets migrate, split and merge at run time
as the data grows.

---

Source: https://nyxdb.io/docs/concepts/architecture/