fluidex/dingir-exchange

Purpose and Executables

Dingir Exchange is a Rust trading-server backend centered on a high-throughput, in-memory order-matching engine. It intentionally excludes account onboarding and cryptocurrency deposit/withdrawal. Runtime binaries separate core trading, durable event processing, HTTP-style REST access, and message inspection:

• src/bin/matchengine.rs

• src/bin/persistor.rs

• src/bin/restapi.rs

• src/bin/dump_unify_messages.rs

Core Matching Engine

The matching engine is a fully asynchronous but single-threaded state owner: order-book mutation, sequencing, trades, balances, and user state should remain within this boundary to preserve deterministic ordering and avoid concurrent state mutation.

• src/matchengine/server.rs

• src/matchengine/controller.rs

• src/matchengine/sequencer.rs

• src/matchengine/market/order.rs

• src/matchengine/market/trade.rs

Requests enter the engine server/controller, are sequenced, then mutate market and account state. Resulting order-state changes, trades, and market data become outbound messages and persistence inputs.

Market, User, and Asset Domains

Market state and trade execution are distinct from user/account balances. Asset management applies balance updates and controls how those updates are emitted or coordinated; user management owns user-level exchange state. This is the primary business-state boundary beneath the controller.

• src/matchengine/market/mod.rs

• src/matchengine/asset/asset_manager.rs

• src/matchengine/asset/balance_manager.rs

• src/matchengine/asset/update_controller.rs

• src/matchengine/user_manager.rs

Messaging and Event Boundary

The system has a dedicated producer/consumer/persistence messaging layer, likely used to decouple engine mutations from durable operation logs and downstream consumers. Kafka is a material external dependency: the project requires librdkafka, and examples include Kafka monitoring.

• src/message/producer.rs

• src/message/consumer.rs

• src/message/persist.rs

• examples/js/kafka_client.ts

This boundary should carry ordered engine outputs rather than allow consumers to directly mutate matching state.

Durability and Historical Storage

Durability combines append-style operation logging with Redis-like fork-and-save snapshots. The persistor component bridges engine/message outputs to durable state; SQL storage holds longer-lived relational records such as trades, kline data, markets, accounts, and transfers.

• src/matchengine/persist/persistor.rs

• src/matchengine/persist/state_save_load.rs

• src/storage/database.rs

• migrations/20200123090047_trade_log.sql

• migrations/20210114140803_kline.sql

PostgreSQL is the documented local dependency, launched alongside Kafka through the orchestration environment.

API Surfaces and Clients

gRPC is the documented primary server interface, implemented with Tokio/Hyper/Tonic. A separate REST API process exposes management, user, public/personal history, trading-view data, and state access; it should query or coordinate with the authoritative engine/persisted data rather than duplicate matching logic.

• src/restapi/mod.rs

• src/restapi/manage.rs

• src/restapi/public_history.rs

• src/restapi/personal_history.rs

• src/restapi/tradingview.rs

JavaScript and Python examples act as external clients and signing/integration references:

• examples/js/RESTClient.ts

• examples/js/ordersigner.proto

• examples/python/put_order.py

Configuration and Deployment

Configuration is layered by environment and service-specific REST settings. Local integration infrastructure is under orchestra; release packaging builds a Docker image.

• src/config.rs

• config/default.yaml

• config/restapi/default.yaml

• orchestra

• release/Dockerfile