Architecture overview

A coordination layer concept for active relational database nodes.

ShardronDB is documented as a Layer 1 architecture concept. It is positioned above relational database nodes to explain gateway routing, write coordination, primary key ownership and backup-node strategy without exposing runtime internals.

This visual gives a high-level view of how applications, a coordination layer, and active nodes can fit together in an active-active model.

See use cases Read Layer 1 docs

ShardronDB architecture diagram showing a coordination layer and active relational database nodes — Architecture matters because the value of active-active systems is created by coordination, ownership, routing, and resilience working together.

Existing database cluster landscape

Traditional relational databases, active-passive HA clusters, multi-primary replication clusters, sharding middleware and native distributed SQL systems all solve different architectural problems. ShardronDB is not described as a universal replacement for those systems; it focuses on a coordination-layer approach for multi-node relational deployments.

Active-passive HAProtects availability, but the write path is commonly concentrated on one active node.

Multi-primary replicationAllows multiple writable nodes, but conflict policy and consistency behavior must be understood carefully.

Distributed SQLProvides native distributed execution and storage, often requiring adoption of a new database platform.

ShardronDBExplores gateway-controlled writes, node ownership, backup placement and primary-key safety above relational nodes.

ShardronDB architecture flow from clients to gateway, PK Guard and active database nodes — The ShardronDB Gateway coordinates active-active relational database nodes and rejects unsafe client-provided primary keys in normal insert flows.

ShardronDB concept

The concept introduces a gateway and write coordination layer between applications and active database nodes.

Client / Application
        ↓
ShardronDB Gateway
        ↓
Request validation + PK Guard
        ↓
Write Coordination
        ↓
Node-local owner table + backup table strategy
        ↓
Monitoring and consistency checks

Primary key collision prevention

Normal client INSERT requests must not provide PK/id values. The real primary key column is discovered from metadata, and the request is rejected before insert if the payload contains that key. Only after this guard passes can the system generate and coordinate the primary key.

INSERT request
        ↓
Contains id / primary key?
   Yes → CLIENT_PK_NOT_ALLOWED
   No  → ShardronDB generates PK
        ↓
Coordinated write flow

Trusted bulk, backup and recovery flows

Backfill, migration, backup apply and recovery apply should not use the normal public gateway insert path. They are treated as trusted internal flows with explicit marking and deterministic mapping. The public rule remains unchanged: normal clients do not send PK/id values.

Public scope

Layer 1 intentionally avoids publishing runtime source code, replication engine internals, production SQL schemas, deployment scripts, secrets, logs, dumps, operational credentials or customer data. The public website explains the architecture, naming, safety boundaries and evaluation model.