01 / 08 Проект
Market Data Platform
Rust инфраструктура от 14 пакета, която отделя приемането, нормализацията, подреждането, разпространението, историческото съхранение и клиентското състояние.
14
Rust пакета в активното workspace
3
Desktop, web и mobile клиента
1
Каноничен протокол за данни
02 / 08 Инфраструктурният проблем
Всеки клиент трябва да вижда един и същ пазар, без да познава суровия формат на доставчика
Платформата превръща provider-specific съобщенията в общ протокол, задава канонична последователност и разпространява едно и също събитие към live delivery, историческо съхранение и клиентско състояние. Replay средата доказва поведението без зависимост от външна мрежа.
Подреждане
Една последователност преди fan-out
Core hub валидира нормализирания envelope, присвоява монотонна hub sequence и изпраща събитието към същите consumer граници при replay и live ingest.
Разпространение
Надеждният път и бързият L1 път имат различни задължения
Snapshots, control и recovery остават по надежден транспорт. Горещите L1 updates могат да използват datagram път, без да променят каноничния payload contract.
Възстановяване
Replay и checkpointing са част от дизайна, а не следаварийна добавка
Детерминистичните fixtures минават през hub, aggregator и client core. Клиентът държи hot state в RAM и извежда versioned checkpoint snapshots извън критичния път.
03 / 08 Платформен стек
Протокол, hub, edge delivery, persistence и клиентско състояние като отделни Rust отговорности
Workspace-ът включва споделен wire protocol, replay harness, core hub, aggregator, QuestDB writer, Postgres-backed app services, headless client core, общ app shell и Dioxus приложения за desktop, web и mobile.
04 / 08 Път на данните
Един нормализиран поток от доставчика до всеки клиент и хранилище
Всяка граница има една работа. Това позволява транспортът, доставчикът или клиентът да се сменят без пренаписване на пазарния модел.
- 01
Provider ingest
Адаптерът премахва provider-specific формата и публикува нормализиран L1 envelope.
- 02
Core hub
Валидира, подрежда и създава каноничния fan-out record.
- 03
Redistribution
Direct, Aeron или Core NATS пренасят вътрешния поток зад един sink contract.
- 04
Edge + history
Aggregator обслужва live сесиите, а market writer съхранява L1 история в QuestDB.
- 05
Client core
Декодира edge frames, управлява subscriptions, stale state, reconnect и checkpoint snapshots.
05 / 08 Решения
Решенията, които оформят системата
Реализирано
Replay и live publish споделят семантика
И двата пътя преминават през една hub validation, sequencing и fan-out граница, за да не се разминава тестовото и реалното поведение.
Реализирано
Provider форматите спират преди hub-а
Hub, aggregator и клиентите работят с общия протокол, а Yahoo и generic JSON/key-value адаптерите остават на входната граница.
Реализирано + опционално
Транспортът е сменяем
Direct и Core NATS пътищата имат конкретни реализации; native Aeron остава feature-gated и изисква отделен media-driver smoke.
Извън hot path
Checkpoint записите не блокират live updates
Client core маркира и извежда snapshots, а конкретното файлово или platform store записване остава зад persistence contract.
06 / 08 Изпълними доказателства
Пътища, които могат да бъдат проверени без маркетингови допускания
- Детерминистичен replay поток: core-hub -> aggregator -> trading-client-core
- Offline provider adapters за key-value, JSON и Yahoo-shaped L1 съобщения през една ingest runtime граница
- Direct, Aeron и Core NATS redistribution contracts с отделни smoke и integration пътища
- QuestDB writer с reconciliation и replay verification за L1 историческо съхранение
- Versioned client-edge decoding и atomic file checkpoint adapter извън критичния live path
08 / 08 Следващият ход
Имате продукт, който зависи от много източници и един надежден вътрешен модел?
Мога да помогна с provider границите, нормализацията, live delivery и persistence архитектурата преди интеграциите да започнат да диктуват продукта.
Обсъдете платформата->Вижте интеграционната услуга->