Introduction
Cerulion Core is built on a dual-transport architecture that optimizes for both local and network communication. This section provides a high-level overview of the system design and how components work together.Design Principles
Zero-Copy First
Local communication uses zero-copy shared memory whenever possible. Serialization only occurs for network transport.
High Availability
Network failures donβt block local communication. The system prioritizes availability over guaranteed network delivery.
Type Safety
Compile-time guarantees in Rust, runtime validation in Python/C++. Prevents message compatibility errors.
Automatic Everything
Serialization, transport selection, and code generation are all automatic. Developers focus on application logic.
Latest-Message Semantics
Network transport uses latest-message semantics. If network is slow, newer messages replace older ones in the queue.
System Overview
Cerulion Core provides a unified pub/sub API that automatically selects the best transport for each communication path:Folder Structure
A typical Cerulion project has the following structure:my-project
.cerulion
config.yaml
state.json
schemas
messages.yaml
services.yaml
nodes
publisher.rs
subscriber.rs
dist
| Directory | Purpose |
|---|---|
.cerulion/ | Configuration and project state |
schemas/ | Message and service schema definitions |
nodes/ | Node implementations |
dist/ | Build output and bundles |