Коллективная ликвидность
1) Зачем это нужно
Мгновенная ликвидность в новых кластерах. Запускаетесь в регионе/нишe — «подмешиваете» общий пул.
Лучшее соответствие и цены. Глубокий рынок → меньше «спред», выше EPI (улучшение эффективной цены/подбора).
Шоки спроса/предложения. Перетекание нагрузки между узлами снижает отказ и очереди.
Экономика. Выше fill rate и ARPU при умеренном росте затрат; возможность cross-sell.
2) Модели коллективной ликвидности
3) Архитектурные компоненты
Ордербук/каталог: абстракции заявка/оффер, статус и версии, SLAs и атрибуты совместимости.
SOR (Smart Order Routing): правила выбора пула/поставщика с учетом цены/качества/юрисдикции/латентности.
Согласованность: CDC и журналы событий, дедуп по `event_id`, компенсирующие транзакции.
Атрибуция и биллинг: кто «владельца» сделки/комиссии, окна претензий, reconciliation.
Качество и репутация: рейтинги/SLA партнера, штрафы, бейджи.
Приватность и локализация: маскирование ПД, гео-пиннинг, правила экспорта событий.
mermaid flowchart LR
U [Demand] --> GW [Routing Gateway]
P1 [Pool A] --- GW
P2 [Pool B] --- GW
P3 [Partner C] --- GW
GW --> SB[Settlement/Billing]
GW --> OBS[Observability/SLO]4) Контракты данных (минимум полей)
yaml offer. v1:
id: uuid kind: product slot capacity price: {amount: decimal, currency: ISO4217}
quality: {rating: 0..5, sla_ttm_ms: int}
geo: {region: "EU", city: "Tallinn"}
vendor: {id: "partner-123", tier: "gold"}
terms: {ttl_s: 60, cancellation: "window:15m"}
version: 7 request. v1:
id: uuid constraints: {geo, time, price_ceiling, compliance}
qos: {max_ttm_ms: 500, min_rating: 4. 0}
trace_id: uuid consent: {...}5) SOR: правила и псевдокод
Критерии ранжирования:- `score = w_priceprice_improvement + w_slattm_slo + w_qquality + w_geodistance_penalty + w_riskvendor_risk_penalty`
python def route(request, pools):
candidates = []
for pool in pools:
if not compliant(request, pool):
continue quotes = pool. quote (request) # timebox, idempotent for q in quotes:
s = score(q, request)
candidates. append((s, pool, q))
ordered = sorted(candidates, key=lambda x: -x[0])
return best_feasible(ordered, fairness=request. fairness)Fairness (справедливость): ротация поставщиков, квоты на долю оборота, tie-break по репутации и недавним выигрышам.
6) Метрики ликвидности
Fill rate = закрытые заявки / все заявки (по сегменту/кластеру).
Time-to-match (p50/p95) — время до подбора/исполнения.
Depth — доступный объем в заданном диапазоне цены/качества.
Spread / EPI — улучшение эффективной цены vs бенчмарка.
Utilization — загрузка предложения (idle% ↓ — хорошо, если без SLA-провалов).
Integrity — доля отмен/фолс-конверсий, расхождение в reconciliation (< ε).
Fairness — дисперсия распределения оборота по поставщикам при равном качестве.
- `fill_rate_month ≥ 92%` в кластере с ≥ N активными офферами.
- `p95_time_to_match ≤ 3s` в пиковые часы.
- `cancel_rate ≤ 1.5%` при SLA поставщика `on-time ≥ 98%`.
7) Наблюдаемость и доказательная база
События: `request.sent`, `quote.received`, `match.made`, `settled`, `cancelled`, `refund`.
Трассировки: `trace_id` сквозной через SOR → пул → поставщик.
Аудит: подписи вебхуков, журнал версий ордербука, «скриншот» котировок.
Reconciliation: двусторонние отчеты, дедуп, расхождения < ε, SLA закрытия претензий.
8) Приватность, комплаенс, суверенитет
Geo-pinning: чувствительные категории/PII не выходят из разрешенного региона.
Псевдонимизация: для межпартнерского обмена — только псевдо-идентификаторы.
Retention как код: TTL событий, право на удаление, Legal Hold.
DPA/вебхуки: подпись, анти-replay, контроль схем.
9) Операционная модель и расчеты
Роли: Market Operator (вы), Пулы/Партнеры (supply), Каналы/Витрины (demand).
Коммерция: RevShare/CPA/минимальные гарантии; «клип» за маршрутизацию/улучшение цены.
Кредиты/штрафы: за срыв SLA, ложные офферы, несогласованность отчетов.
Settlement: периодичность T+N, удержания, chargebacks, отчетность.
yaml partner_id: "pool-A"
sla:
fill_rate: ">= 90%"
on_time: ">= 98%"
quote_ttl_s: 2 limits:
rps: 200 region: ["EU","TR"]
commercials:
model: "revshare: 20% of net"
security:
webhook_signature: "Ed25519"10) Паттерны интеграции
Pull-quote API с тайм-боксом (idempotency-key).
Подписанные Webhooks для `match.made`/`settled` (ретраи с экспонентой).
Event bus для CDC ордербука и аналитики (версии событий).
Batch-recon (ежедневный SFTP/Blob + контрольные суммы).
Outbox/Inbox у обоих сторон + дедуп.
Версионирование схем/SDK, окно совместимости.
11) Управление перегрузкой и качелями
Анти-конгестия: лимитеры, очереди, приоритизация VIP/сложных кейсов, surge-коэффициенты.
Анти-арбитраж (токсичный): запреты «самоисполнений» по заниженной цене/качеству, мониторинг «ping-pong» запросов.
Анти-фрод: device/поведенческие сигнатуры, honey-tokens, отложенная квалификация (cool-off).
Деградация с честью: fallback на локальный пул, «best-effort» с прозрачным ухудшением.
12) Примеры логики (скетчи)
12.1 Роутинг с учетом юрисдикции и SLO
python def compliant(req, pool):
return (req. constraints. geo in pool. regions and pool. sla. quote_ttl_s <= 2 and pool. vendor_tier in {"gold","silver"})12.2 Политика справедливости (Rego-идея)
rego package fairness deny["overexposed vendor"] {
usage. share[input. vendor] > 0. 45 input. vendor. tier == "silver"
}12.3 Проба конвергенции ордербука
sql
SELECT offer_id, MAX(version)-MIN(version) AS drift
FROM orderbook_events
WHERE ts >= now() - interval '5 minutes'
GROUP BY 1
HAVING MAX(version)-MIN(version) > 1; -- fragmentation signal13) Метрики зрелости
Coverage: доля сегментов/регионов, где есть ≥ X активных офферов.
Elasticity: как быстро fill rate восстанавливается при +Δ спроса.
EPI/Spread-improvement: выгода от агрегации vs соло-пул.
Fair-distribution: отклонение доли оборота от ожидаемой по качеству.
Recon-health: частота/срок закрытия расхождений.
Privacy-score: доля маршрутов без выноса ПД за границы политики.
14) Анти-паттерны
Голая федерация без SOR и правил качества → фрагментация, отмены.
«Стеклянный рынок»: открываете все всем — всплеск фрода и ценовой войны.
Нет атрибуции и reconciliation → вечные споры и замороженные выплаты.
Жесткая синхронщина между пулами → каскадная латентность/отказы.
Одинаковые правила для разных сегментов → деградация опыта в премиум/локальных нишах.
Игнорирование TTL офферов → сделки по «протухшим» условиям.
Единый ключ шифрования на весь рынок → невозможно точечно «стереть» данные.
15) Чек-лист архитектора
1. Определены модель (общий пул/федерация/хаб) и ограничения суверенитета?
2. Есть контракт данных (схемы, версии, TTL, подписи) и окно совместимости?
3. Реализован SOR с fairness и бэкомпами, SLO ликвидности и дашбордами?
4. Прописаны биллинг/атрибуция, окна претензий, кредиты/штрафы?
5. Встроены анти-конгестия/анти-фрод/анти-арбитраж и режим деградации?
6. Налажен reconciliation и артефакты «доказательства сделки»?
7. Приватность: псевдонимизация, geo-pinning, ретеншен, право на удаление?
8. Учения: стресс-пики спроса/падение пула/рассинхронизация ордербука?
9. FinOps: бюджет egress, стоимость маршрутизации, целевой EPI?
10. Governance: пороговые доли, сертификация партнеров, аудит.
Заключение
Коллективная ликвидность — это не «подключить еще одного партнера», а спроектировать рынок: единые контракты и события, прозрачные правила маршрутизации и справедливости, сильная наблюдаемость и расчеты, приватность и юрисдикции «как код». Так из разрозненных источников рождается единый, глубокий и устойчивый бассейн спроса и предложения — с лучшим опытом для пользователей и предсказуемой экономикой для всей экосистемы.