System Design

Core Stack

client -> transport -> TCP/TLS -> transport -> server -> engine

That line is the main architectural rule.

Layer Responsibilities

client

• parses user input through the shared command crate
• opens TCP or TLS connections
• performs startup negotiation and optional AUTH
• renders responses in plain, table, or json

transport

• owns VTP2 framing
• encodes and decodes request and response payloads
• handles startup negotiation
• applies compression and checksum rules
• provides sync and async I/O helpers

server

• accepts TCP/TLS/mTLS sessions
• enforces authentication and RBAC
• enforces request limits, rate limits, and idle timeouts
• manages maintenance mode
• records audit events
• routes validated commands into the engine worker

engine

• owns the in-memory key/value state
• applies expirations
• persists snapshots and segmented WAL
• recovers from persisted storage
• performs logical backup/restore and offline PITR-oriented restore

Why the Engine Worker Exists

The server accepts multiple client connections concurrently, but mutating engine work is still serialized through a dedicated engine worker.

That gives:

• deterministic single-node ordering
• a clean place for atomic transaction application
• less shared-state complexity in the async server path

It is a deliberate single-node design, not a distributed concurrency model.

Persistence Model

Current persisted state is built from:

• encrypted snapshots
• segmented encrypted WAL
• manifests
• a server-managed storage keyring

Snapshot flow:

1. purge expired keys
2. seal the active WAL segment
3. write the encrypted snapshot
4. write the manifest
5. create a new active segment
6. prune sealed segments older than retention

Recovery flow:

1. load keyring
2. verify and load manifest
3. decrypt and load snapshot
4. replay retained WAL segments in order

Operational Controls

The server runtime currently includes:

• default-on auth
• RBAC enforced before engine execution
• optional TLS and mTLS
• rate limiting
• transaction queue and lifetime limits
• maintenance mode
• logical backup/restore
• offline storage verification, migration, and PITR-oriented restore

Current Boundaries

What Vaylix does not implement today:

• replication
• sharding
• MVCC
• distributed transactions
• formal distributed ACID

Those are roadmap boundaries, not current runtime features.