Why Vaylix

Vaylix is opinionated about boundaries. The engine should not know about sockets, frame parsing, TLS, or request decoding. That rule keeps the system easier to evolve in three ways.

1. Protocol and Storage Stay Separate

The engine owns:

• state
• WAL
• snapshots
• expirations
• single-node transaction application

The transport owns:

• framing
• checksums
• opcodes
• request and response encoding
• default-on outbound frame compression

That separation is what allows the current client and server to share one wire layer instead of copying binary parsing logic around the codebase.

2. Future Replication Has a Place to Live

Vaylix does not implement replication or sharding yet, but the current shape already reserves space for it:

• request IDs are UUIDs
• frame headers have explicit flags
• client and server both depend on the transport crate
• engine mutations flow through a dedicated runtime worker

Those are the kinds of decisions that make future cluster traffic possible without rewriting the storage engine around network concerns.

3. Operations Matter

The shipped implementation already treats operational behavior as first-class:

• TLS support with explicit opt-in
• mTLS support with client-certificate verification
• auth enabled by default
• zstd frame compression enabled by default
• encrypted-at-rest persistence
• audit logging
• request quotas and rate limiting
• Docker-friendly data directory layout

Vaylix is not aiming to be a toy server with a pretty CLI. The goal is a maintainable foundation with a clear path from local single-node deployment to a more capable system later.