Skip to content

Architecture Overview

Meridian is a pluggable investment management platform. The platform provides the kernel (order lifecycle, positions, cash, settlement), the message bus (pub/sub communication), and the sidecar (plugin isolation). Everything else is a plugin.

Three Guarantees

  1. Full Instance Recoverability — any plugin lost and relaunched reconstructs its state from durable stores. No data is lost.
  2. Full Message Observability — every message passes through three correlated observation points (two sidecars + Bus API), all carrying the same trace_id/correlation_id.
  3. Zero External Dependencies — a plugin's only contract is its local sidecar on localhost:9191. The plugin is unaware of middleware, cloud topology, other instances, or restarts.

Data Flow

DGM (market data)
  → Signal Engine (alpha signals)
    → Portfolio Optimizer (target weights)
      → OMS (compliance checks)
        → EMS (smart order routing)
          → CCM (broker/venue)
            → fills flow back
              → BOR (positions, cash, NAV)

Every arrow is a pub/sub message on the bus. No plugin talks directly to another.

The Kernel

The kernel is a unified, event-sourced engine that tracks the full order lifecycle. OMS, EMS, and BOR are not separate systems — they are API surfaces over a single kernel.

16 Order States

CREATED → PENDING_COMPLIANCE → COMPLIANCE_APPROVED → OPEN →
PARTIALLY_FILLED → FILLED → PENDING_SETTLEMENT → SETTLED

Branch states:
COMPLIANCE_REJECTED, REJECTED, CANCELLED, EXPIRED,
PENDING_CANCEL, PENDING_MODIFY, SUSPENDED, CLOSED

Every state transition is recorded as an immutable event with dual timestamps (ts_event from the source, ts_init from the kernel).

Kernel Entity Model

Entity Description
Order The full lifecycle from creation to settlement
Allocation Block-to-account assignment
Placement A child order sent to a venue
Response A fill or rejection from a venue
Position Share quantity per instrument, derived from fills
CashMovement Cash debit/credit per transaction

API Surfaces

Surface Purpose Key Operations
OMS Order management + compliance Create/modify/cancel orders, compliance checks, allocations
EMS Execution management Route to venues, algo selection, RFQ, fill aggregation
BOR Book of record Positions, cash, NAV, tax lots, reconciliation, settlement

All three share the same underlying kernel. An order created via the OMS API is the same entity that the EMS routes and the BOR records positions for.

The Message Bus

All inter-plugin communication flows through the bus. The bus supports multiple backends:

Backend Profile Use Case
NATS Default Development, low-latency general purpose
Kafka Durable Production, audit logging, regulatory compliance
Aeron Ultra-low-latency High-frequency trading, market making
Cloud (SQS, Pub/Sub, Service Bus) Managed Cloud-native deployments

Topic Naming

Topics follow the pattern:

platform.{domain}.{scope}.{entity}.{action}

Examples:

Topic Description
platform.data.eod.AAPL End-of-day price for AAPL
platform.signal.momentum-1.alpha Alpha signal from a signal engine
platform.oms.main.order.cleared Order cleared by compliance
platform.ccm.broker-a.fill.AAPL Fill from a broker

The Sidecar

Every plugin runs alongside a sidecar process. The plugin talks only to the sidecar on localhost:9191 via gRPC. The sidecar handles:

Responsibility What it does
Pub/sub Routes messages to/from the bus
ACL enforcement Plugin can only access topics it's authorized for
Schema validation Messages must conform to declared protobuf schemas
Audit logging All messages are written to the immutable audit log
Health monitoring Heartbeat, liveness, readiness probes
State recovery Rebuilds plugin state from durable store on restart
Entitlements Checks plugin's license and feature flags at startup

Why a Sidecar?

The alternative is embedding bus logic in the SDK. The sidecar approach means:

  • Language independence — the SDK is thin (gRPC client). Complex logic lives in the sidecar (Go).
  • Consistent security — ACL and audit happen at the infrastructure level, not in user code.
  • Upgradeability — upgrade the sidecar without changing plugins.
  • Zero trust — the plugin cannot bypass ACL or audit because it never touches the bus directly.

Plugin Types

Type Role Examples
DGM (Data Gateway Manager) Inbound market data Bloomberg feed, exchange direct, CSV file import
Signal Engine Consumes data, generates alpha signals Momentum, mean reversion, ML model
Portfolio Optimizer Converts signals to target weights Mean-variance, risk parity, equal weight
OMS (Order Management) Compliance checks, order routing Pre-trade compliance, allocation
EMS (Execution Management) Smart order routing, algo selection VWAP, TWAP, RFQ, algo wheel
CCM (Capital & Connectivity Manager) Broker/venue connectivity FIX broker adapter, exchange API
BOR (Book of Record) Positions, cash, settlement Transaction ledger, NAV calculation
Valuation Mark-to-market pricing QuantLib-based, vendor pricing
Compliance Rule evaluation Concentration limits, restricted lists

Vendors build plugins. The platform provides the kernel, bus, and sidecar.

Deployment Model

Four Tiers

Tier Who Owns
Platform Meridian Kernel definitions, security master, legal entity directory, plugin registry
Vendor Plugin developers Plugin code, marketplace listings
Deployment Fund/firm All data — orders, positions, compliance records, audit trail
User Individual Role-scoped access within a deployment

Data Ownership

The deployment (your fund) owns all data. Meridian's control plane stores deployment metadata and plugin registry entries — never your trade records, positions, or audit trails.

If Meridian ceases to exist, your deployment continues to run. The kernel (meridian-core) is Apache 2.0 open source.

Next Steps

Ready to build?

Now that you understand the architecture: