Replication engine
Capture changes as movement events
Object, stream, and telemetry changes enter product-owned routes built for distributed environments.
Architecture overview
Replication architecture for data you operate anywhere
Stornamics is built as a replication spine for product routes: capture workload changes, keep the history needed for replay and recovery, and move data through node-aware routes across cloud, on-premise, and hybrid sites.
01Capture product events
Object writes, broker records, and telemetry signals enter their owning route.
02Preserve replay history
Retained changes keep recovery, diagnostics, and inspection grounded in what happened.
03Place node-aware routes
Cloud, on-premise, and hybrid nodes receive the data paths they are meant to operate.
04Operate with route context
Identity, status, limits, and diagnostics stay attached to each product path.
Event history
Preserve what changed for replay
Retained records, stream cursors, and segment bundles give teams something concrete to replay, recover, and inspect.
Node awareness
Place routes across real sites
Sites, zones, identity, diagnostics, and limits describe which nodes participate and how each route is operated.
How the system fits together
Replication turns workload history into placement
A route starts with product events, carries the history needed for replay or recovery, and places data across nodes, sites, and zones with operational controls attached.
- 01
Capture workload changes
Objects, stream records, queue activity, and telemetry signals enter the route through the product that owns them.
- 02
Preserve history for replay and recovery
Retained events, cursors, WAL records, and segment bundles keep movement inspectable instead of hiding it inside opaque sync jobs.
- 03
Place replicas where nodes operate
Sites and zones connect product routes to cloud, on-premise, and hybrid nodes with identity, diagnostics, and status nearby.
Current product proof points
What each product route proves today
These proof points make the replication architecture concrete without stretching private beta into a production promise. Each card names the route, the history it keeps, and the boundary that keeps evaluation scoped.
Object route
Scoped S3 Core object workflows
ObjectDB
ObjectDB's public proof point is the scoped S3 Core gateway: bucket and object workflows with documented compatibility, request limits, and explicit unsupported-surface behavior.
- Buckets and objects cover discovery, create, read, list, delete, range-read, multipart-upload, tag, metadata, delegated-URL, and browser POST workflows inside the named profile.
- Advanced S3 families, AWS IAM equivalence, and the native ObjectDB model stay outside this current route until docs and status move them forward.
Event route
Streams, queues, cursors, and replay
Message Broker
Message Broker's proof point is a private-beta route family for streams, records, cursors, replay, shared queues, auth, metrics, audit, and diagnostics.
- Streams can be created, records published and fetched, replayed, and coordinated with cursor and consumer-group operations.
- Shared queue flows include claim, lease renewal, ack, nack, retry, and dead-letter handling while replication outcomes and Kafka compatibility stay bounded.
Telemetry route
OTLP ingest, query, WAL, and segments
LogDB
LogDB's proof point is telemetry admission and retained-record query through endpoint JSON, OTLP logs and traces, local WAL, and segment bundles.
- HTTP/protobuf, JSON compatibility, optional configured gRPC ingest, and POST /v1/query give evaluators a concrete read/write path for logs and traces.
- S3 query-read, BYOC, public replay APIs, external sinks, metrics, profiles, dashboards, and SIEM positioning remain separately bounded.
Trust layer
Status and limits stay close to every route
Availability, compatibility, and limits are part of the architecture story. Use them together before turning a current route into an evaluation plan.
ObjectDB
Private Beta- Current availability
- Private Beta
- Public beta
- Current route
- S3 Core gateway
- Verify before relying on
- advanced S3 families, AWS IAM equivalence, or the native ObjectDB model
Message Broker
Private Beta- Current availability
- Private Beta
- Public beta
- Current route
- HTTP v1 private-beta routes
- Verify before relying on
- replication outcomes, Kafka compatibility, or unrestricted broker replacement
LogDB
Private Beta- Current availability
- Private Beta
- Public beta
- Current route
- OTLP/query v1
- Verify before relying on
- S3 publication, public replay APIs, external sinks, metrics, profiles, dashboards, or SIEM positioning
Core engine
Replication Engine
Stornamics is built around a replication engine that turns workload changes into product-owned movement events. Object updates, stream records, queue activity, and telemetry writes can move across the places a team operates while preserving the history needed for replay, recovery, and inspection.
- Asynchronous movement lets work continue while data is synchronized between approved cloud, on-premise, and hybrid locations.
- Event history records what changed so replay, retained records, recovery review, and diagnostics have concrete material to inspect.
- Durability, recovery, performance, and scale details stay connected to the product route and its documented limits.
This is the architecture spine: product engines own data movement, and the surrounding controls make each route visible.
Product surfaces
Product Engines on the Same Replication Spine
ObjectDB, Message Broker, and LogDB share the same placement and operations model, but each implements a different technical surface. That gives teams one architecture for distributed data movement without pretending every workload belongs in the same engine.
- ObjectDB handles S3 Core bucket and object workflows near cloud, on-premise, or hybrid workloads.
- Message Broker handles streams, queues, cursors, replay, auth, audit, metrics, and diagnostics for event-driven systems.
- LogDB handles OTLP ingest, local query, WAL-backed records, and segment bundles for operations data that needs to land where systems run.
The result is more concrete than a platform promise: each product engine owns how its data is captured, retained, moved, and observed.
Topology control
Node-Aware Sites and Zones
A site or zone is not just a label on a diagram. It describes where nodes run, which environments participate, and how data-placement choices relate to retention, privacy, latency, analytics access, and recovery planning.
- Represent cloud regions, on-premise facilities, hybrid environments, and local evaluation nodes in one topology model.
- Separate operational copies, analytics copies, retention windows, and locality needs with visibility into product limits.
- Compare latency, locality, retention, privacy, and recovery tradeoffs before teams commit to a deployment shape.
The topology model makes placement an architectural control, not an after-the-fact migration project.
Operations layer
Control Plane for Configuration, Identity, and Observability
The replication spine needs a control plane. Stornamics treats service configuration, identity, diagnostics, auditability, and support artifacts as part of how customers operate distributed product routes.
- Nodes and services receive product-scoped configuration and identity boundaries.
- Audit, metrics, diagnostics, and support bundles stay attached to the route that generated them.
- Security and privacy controls are documented alongside tenancy and data-handling behavior.
Operators can see which route is running where, what controls apply, and which diagnostics or status signals to inspect.
