How It Works¶
The 30-Second Version¶
You write trading logic as a plugin. The kernel handles order lifecycle,
positions, cash, and audit. A sidecar on localhost:9191 handles messaging,
access control, and recovery. Plugins never talk to each other directly — they
communicate through a message bus. That's it. Everything else is detail.
Data Flow¶
A signal starts as raw market data and flows through the pipeline until it becomes a recorded position:
graph LR
DGM["DGM<br/><small>market data</small>"] --> SIG["Signal Engine<br/><small>alpha signals</small>"]
SIG --> PO["Portfolio Optimizer<br/><small>target weights</small>"]
PO --> OMS["OMS<br/><small>compliance checks</small>"]
OMS --> EMS["EMS<br/><small>smart order routing</small>"]
EMS --> CCM["CCM<br/><small>broker / venue</small>"]
CCM -- "fills" --> BOR["BOR<br/><small>positions, cash, NAV</small>"]Every box is a plugin. Every arrow is a message on the bus. Replace any box without touching the others.
Three Guarantees¶
Full Instance Recoverability
Any plugin can crash, restart, and reconstruct its complete state from the event log. No data is lost. No manual intervention required. Your 3 AM pages become non-events.
Full Message Observability
Every message passes through three correlated observation points — publish, route, deliver. You get a complete audit trail of every decision the system made, searchable and replayable.
Zero External Dependencies
A plugin's only contract is its local sidecar on localhost:9191. No
service discovery, no DNS tricks, no cloud-specific SDKs. If your code can
open a gRPC connection to localhost, it can run on Meridian.
You Focus on Logic, Meridian Handles the Rest¶
Write a signal engine. Write an execution algorithm. Write a compliance rule. The platform takes care of everything else:
- Message routing — pub/sub with topic-based filtering
- Order lifecycle — new, partial fill, filled, cancelled, rejected
- Position tracking — real-time shares, cash, and settlement state
- Access control — per-plugin, per-topic permissions
- Audit logging — every message, every state change, every decision
- State recovery — automatic replay on restart
Architecture at a Glance¶
graph TD
UI["Management UI"]
BUS["Bus API · Execution Kernel<br/><small>gRPC / HTTP · Event-sourced state</small>"]
UI --> BUS
subgraph plugins [" "]
direction LR
DGM["<b>Data Gateway</b><br/><small>Sidecar</small>"]
SIG["<b>Signal Engine</b><br/><small>Sidecar</small>"]
OMS["<b>OMS</b><br/><small>Sidecar</small>"]
CCM["<b>Broker Adapter</b><br/><small>Sidecar</small>"]
VAL["<b>Valuation</b><br/><small>Sidecar</small>"]
end
BUS --- DGM
BUS --- SIG
BUS --- OMS
BUS --- CCM
BUS --- VALEvery plugin runs alongside a sidecar — a lightweight process that handles the protocol so your code doesn't have to.
The Sidecar¶
The sidecar is your plugin's gateway to the platform. It handles pub/sub messaging, access control, schema validation, audit logging, health monitoring, state recovery, and entitlement checks. Your plugin talks to the sidecar over gRPC on localhost. The sidecar talks to the bus. You never touch the bus directly.
Four Tiers¶
The platform separates responsibilities cleanly:
| Tier | Who | What They Own |
|---|---|---|
| Platform | Meridian | Kernel, security master, plugin registry, sidecar runtime |
| Vendor | Plugin developers | Plugin code, marketplace listings, pricing |
| Deployment | Your fund | All data — orders, positions, cash, audit trail |
| User | Individual | Role-scoped access within a deployment |
Data Ownership¶
Your data stays yours
The deployment owns all data. Orders, positions, fills, audit logs — everything lives inside your deployment boundary. Meridian the company never sees your trading data.
If Meridian ceases to exist, your deployment continues to run. The kernel, SDKs, CLI, and documentation are all Apache 2.0 open source. No vendor lock-in. No hostage situations.
Want the deep technical details?
Kernel model, sidecar protocol, plugin specifications, message schemas — it's all open source.